Add dependabot to sv2

[Shourya742]

This PR adds Dependabot, a bot that automatically keeps project dependencies up to date. It introduces a dependabot.yml configuration that checks daily for updates to stratum-core. If an update is available, it opens a PR to bump the dependency.

Currently, it will open three separate PRs for pool-apps, miner-apps, and integration-test. Once we adopt a more structured workspace layout after the JDS merge, this will be consolidated into a single PR.

more on dependabot here: https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/dependabot-quickstart-guide

[Shourya742]

If we get dependabot in, we will no longer need stratum-freshness ci workflow, as the bot will take over responsibility for keeping stratum-core updated to the latest main branch.

[Shourya742]

Removed freshness workflow: 8b6ad65

[plebhash]

checks daily for updates

hmm I wonder if we couldn't do something that is triggered automatically?

more often than not, if we have to wait for an entire day, we're most likely going to have to do it manually anyways

Currently, it will open three separate PRs for pool-apps, miner-apps, and integration-test.

this also feels a bit suboptimal? one PR should be ideal, regardless of workspace structure

---

both points above seem to be fundamental limitations on dependabot, which makes me wonder if we should really leverage it for this

[lucasbalieiro]

more often than not, if we have to wait for an entire day, we're most likely going to have to do it manually anyways

Yeah, I was with this same thing in my mind?

What if we used the same logic we use for the specs? see: https://github.com/stratum-mining/sv2-spec/blob/main/.github/workflows/dispatch-update.yml

Every commit on main, we dispatch some workflow in the website repo. The use case for the spec is just to update the submodule, but maybe we could adapt the logic.

But, of course, this will introduce few more edge cases to deal with, like:

• if two more commits are added in the same day to the stratum core, it shouldn't create two separate PRs here, for example.

I was looking at the dependabot docs and wasn't able to find something that triggers the check based on another repo activity.

[plebhash]

created these as an alternative:

• ci: dispatch stratum main updates to sv2-apps stratum#2121
• ci: replace stratum freshness check with event-driven stratum-core sync #353

[Shourya742]

checks daily for updates

hmm I wonder if we couldn't do something that is triggered automatically?

more often than not, if we have to wait for an entire day, we're most likely going to have to do it manually anyways

Currently, it will open three separate PRs for pool-apps, miner-apps, and integration-test.

this also feels a bit suboptimal? one PR should be ideal, regardless of workspace structure

both points above seem to be fundamental limitations on dependabot, which makes me wonder if we should really leverage it for this

hmm..All the changes to stratum-core are either something which doesn't affect the sv2-apps, like some test addition, fuzz, and others. For which even the deferred updates are kinda ok. For cases, where we have some changes which break the sv2-apps, we do have a companion PR for them on sv2-apps.

Like I am ok with deferred updates.

Ya, the three PR bottleneck is a real bummer, like its only because how we manage our workspaces currently. I guess, now with new JDS, we can group all crates in a single workspace. That's a separate discussion though.

If we do it via the CI or our bot, thats cooler.

[plebhash]

ok I think @Shourya742 raises fair points on his comment above.

I guess the main point here is getting rid of our main bottleneck, which is the stratum-freshness job inside .github/workflows/lockfiles.yaml

both approaches do this, and everything else are secondary tradeoffs.

therefore no hard opinions on whether we do it via dependabot or my alternative PRs.