chore: add dependabot.yml

[PavelSBorisov]

Description:

Adding dependabot.yml

Related issue(s):

Fixes #3640

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[github-actions]

Test Results

 20 files  ± 0  280 suites  +3   18m 5s ⏱️ -6s
712 tests +23  707 ✅ +25  5 💤 ±0  0 ❌  - 2 
728 runs  +10  723 ✅ +12  5 💤 ±0  0 ❌  - 2 

Results for commit 2501eaf. ± Comparison against base commit 0e189dc.

This pull request removes 1 and adds 24 tests. Note that renamed tests count towards both.

"before all" hook for "@release should deploy a contract" ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs "before all" hook for "@release should deploy a contract"

@release should deploy a contract ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs @release should deploy a contract
should be able to return more than 2 logs with limit of 2 logs per request ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs should be able to return more than 2 logs with limit of 2 logs per request
should be able to use `address` param with a large block range ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs should be able to use `address` param with a large block range
should be able to use `address` param with multiple addresses ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs should be able to use `address` param with multiple addresses
should be able to use `address` param ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs should be able to use `address` param
should be able to use `blockHash` param ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs should be able to use `blockHash` param
should be able to use `fromBlock` param ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs should be able to use `fromBlock` param
should be able to use `topics` param ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs should be able to use `topics` param
should be able to use range of `fromBlock` and `toBlock` params ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests eth_getLogs should be able to use range of `fromBlock` and `toBlock` params
should execute a post EIP-1559 transaction with "eth_sendRawTransaction" and pays the total amount of the fees on behalf of the sender ‑ RPC Server Acceptance Tests Acceptance tests @api-conformity @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Transaction related RPC Calls Check subsidizing gas fees given PAYMASTER_ENABLED=true, PAYMASTER_WHITELIST=*, MAX_GAS_ALLOWANCE_HBAR=100 are set should execute a post EIP-1559 transaction with "eth_sendRawTransaction" and pays the total amount of the fees on behalf of the sender
…

♻️ This comment has been updated with latest results.

[quiet-node]

Hey @PavelSBorisov, I noticed this PR hasn’t been updated in a while. Is it still relevant?

[PavelSBorisov]

Hey @PavelSBorisov, I noticed this PR hasn’t been updated in a while. Is it still relevant?

Hey @quiet-node, yes it's still relevant but has been sitting on the back burner due to other priorities until now.
I'll be taking another look at it today.

[lfdt-bot]

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

[quiet-node]

Hey @PavelSBorisov are there any updates on this?

[PavelSBorisov]

Hey @PavelSBorisov are there any updates on this?

Updated in accordance with the comments, awaiting review.

[andrewb1269hg]

Couple minor things.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@            Coverage Diff             @@
##             main    #3725      +/-   ##
==========================================
+ Coverage   86.66%   89.72%   +3.06%     
==========================================
  Files          87       87              
  Lines        5039     5002      -37     
  Branches     1020     1008      -12     
==========================================
+ Hits         4367     4488     +121     
+ Misses        409      263     -146     
+ Partials      263      251      -12     

Flag	Coverage Δ
config-service	95.74% <ø> (-0.05%)	⬇️
relay	83.43% <ø> (+2.16%)	⬆️
server	80.95% <ø> (+0.13%)	⬆️
ws-server	83.86% <ø> (+22.85%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 21 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[acuarica]

Hi @PavelSBorisov, we started to see the effects of this config file. We noticed that many, many PRs were created. The problem is that these many PRs degrade GHA performance substantially. Right after the PRs are created, workflows stop running for while. Is there is a way to create PRs in batches? Or at least for now, maybe even decrease the number of PRs created so we can continue working while dependabot PR workflows are running.

I noticed this article https://docs.github.com/en/enterprise-cloud@latest/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates, maybe we can use the cooldown setting? Any other ideas?

[PavelSBorisov]

Hi @PavelSBorisov, we started to see the effects of this config file. We noticed that many, many PRs were created. The problem is that these many PRs degrade GHA performance substantially. Right after the PRs are created, workflows stop running for while. Is there is a way to create PRs in batches? Or at least for now, maybe even decrease the number of PRs created so we can continue working while dependabot PR workflows are running.

I noticed this article https://docs.github.com/en/enterprise-cloud@latest/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates, maybe we can use the cooldown setting? Any other ideas?

@acuarica the current dependabot PR flood is expected until everything is up to date, after which PRs would slow down.

What we can do to ease the load a little meanwhile is apply a 1 day cooldown setting to the daily interval PRs - this would basically make dependabot open new PRs every other day for these deps instead of daily.

We could, alternatively, significantly lower the number of dependabot PRs allowed to sit open at one time (from 20 to 10/5) which would mean that when dependabot performs the daily check, it would open a maximum of 10/5 PRs (if all the previous ones are closed) and so it would keep the runners busy for a lot less time.

[acuarica]

Hi Pavel, we discussed this internally with the team. We would like to apply your suggestions, that is

• 1 day cooldown
• and lower the amount of open PRs (from 20 to 5)

Over time we can increase this limit once most of the repo's dependencies are up to date. Would this be possible?