Dependabot-like GitHub action for Scarb

[mkaput]

Problem

We would love to have a Dependabot-like experience for having some entity automagically bumping dependencies in Cairo repositories. Unfortunately, Dependabot does not have a facility to provide implementations of custom package managers by the community, so we have to make workarounds.

Proposed Solution

High-level idea

The idea is to make use of GitHub actions and their scheduled workflow triggers functionality.

For the purpose of this issue, let's call it dependascarbabot (sounds cool, isn't it?). But I'm not enforcing this name 🤡

The template GHA workflow that users would paste into their repositories could look like this:

on:
  schedule:
    - cron: '0 3 * * 1'  # At 03:00 on Monday.

jobs:
  dependascarbabot:
    runs-on: ubuntu-latest
    steps:
      - run: owner/dependascarbabot@v1

The less boilerplate, the better

I think the less boilerplate users would have to maintain, the better. So, if possible, this action should call all of actions/checkout, software-mansion/setup-scarb, git commit and git push under the hood if possible.

How should updating be done?

There is scarb update command. It drops the Scarb.lock file and regenerates it, forcing Scarb to pull the latest dependencies matching requirements specified in Scarb.toml. I think that's a good starting point, even MVP-worthy.

This command is not as smart as Dependabot proper because Dependabot would also try to modify the Scarb.toml file, aiming to bump the requirements if possible. Then, it would let maintainers decide whether to accept the PR or not, but running CI over this change. That's something worth implementing, though! I think there's a space for something like this in Scarb, either as a feature of scarb update, or a separate command (like yarn upgrade-interactive), which should then be used by this new action.

Preparing a summary of what dependencies have been updated

I have no idea what would be the best way to extract from scarb update doings what dependencies have been updated. I'm leaving this topic entirely to the person who implements this.

Notes

Useful resource:

1. https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
2. https://github.com/software-mansion/setup-scarb

[okhaimie-dev]

I will love to attempt this.

[mkaput]

The task is yours 💞

[okhaimie-dev]

Awesome! I will share an MVP before noon Friday CST

[mkaput]

Nice 🤩 Though, don't enforce any deadlines on you mate! No need to rush it.

[okhaimie-dev]

Alright. Quick update:

Here is the repo, I am building the custom action in
https://github.com/okhaimie-dev/dependascarbabot

I will make additional push with my progress soon, and I am also willing to transfer it to software-mansion organization once it works fine. That is if y'all are open to that.

[mkaput]

Awesome! Can't wait to see the progress :D

You can leave this repository under your name and maintenance. I think moving it to our org would make it more complicated for you to work on.

[maciektr]

Hi @okhaimie-dev !
Are you still working on this? Do you need any help from the team?

[mkaput]

Moving this issue back to backlog due to no activity. It's open for contributions again! :)

[cwastche]

Is this issue still open ? If so I'd love to have a crack at it.

[maciektr]

Hi @cwastche!
Great! Assigned to you. Have fun!

[cwastche]

Hi @maciektr ! This is the current repo for a MVP GHA that will bump cairo dependencies by running the 'scarb update' and creating a PR with the new changes: https://github.com/cwastche/Dependascarbabot
Would love some feedback if necessary.

Regarding version resolution, is the plan still to use PubGrub, and has any work already been done in that regard ?

[maciektr]

Hi @cwastche !

I've tested your actions and for me it's a great first iteration! ❤️ ❤️ ❤️ Superb effort!

Two minor suggestions:

• I am not sure about printing diff in PR description. This can grow with time, and the PR itself acts as a diff just fine.
• It would be perfect if the action had an option to specify scarb version (the current default is fine) to use and repo directory to run in, for added flexibility.

One concern:
In general PAT tokens must be considered risky, as they give you read/write access to all repositories the user's account has access to. Have you considered other alternatives, like the new fine-grained tokens or even the default GITHUB_TOKEN (more here)? I am aware the second one comes with some problems, not really sure about the first one (is it rolled out to all users already? 🤔 )?

Nevertheless, the usage guide in your README would benefit from a short note on the risks associated to token use and a short instruction on token management (to store PAT in github secrets, as I expect some users will get lost here otherwise).

Otherwise, I don't think I have more suggestions.
Once again, thank you very much for developing our community!!! 😍