frizbee fails to pin the version of ruby/setup-ruby

[Moisan]

Describe the issue

frizbee fails to pin the version of the ruby/setup-ruby action when the version is setup-ruby@v1.

To Reproduce

• Download the following github action file: wget https://raw.githubusercontent.com/Homebrew/ci-orchestrator/e791dc96262bfd324d1e5238f428e68d2ef7ecca/.github/workflows/main.yml
• frizbee actions main.yml

Note that no update is done to setup-ruby. I would expect to see a change from setup-ruby@v1 to something like

ruby/setup-ruby@161cd54b698f1fb3ea539faab2e036d409550e3c # v1.187.0

What version are you using?

0.0.20

[rdimitrov]

hey, @Moisan, thanks for raising this issue. I can confirm that I tried the steps you provided and I was able to reproduce it locally 👍

[jhrozek]

The issue is that ruby/setup-ruby@v1 is a branch, not a tag. By default, frizbee won't pin branches because the assumption we made is that if you use a branch, typically you want to follow the branch (a typical example is myaction@master).

This is configurable, e.g. with a config like this:

ghactions:
  exclude_branches:
    - main
    - master
  exclude:
    # Exclude the SLSA GitHub Generator workflow.
    # See https://github.com/slsa-framework/slsa-github-generator/issues/2993
    - slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml

stored in .frizbee.yml the action can be resolved:

frizbee actions ruby/setup-ruby@v1
ruby/setup-ruby@161cd54b698f1fb3ea539faab2e036d409550e3c

I am not sure if dependabot would update the action though, this needs some more testing.

[jhrozek]

The other option would be to modify the workflow to use a tag in the first place:

uses: ruby/[email protected]

then frizbee should be able to pin the action and put the magic comment in that helps dependabot to upgrade the action.

[Moisan]

I see, I didn't know that this action was using a branch instead of a tag. I think frisbee warning about that would be useful.

Also note that I was using frizbee from the command line, not trough the action.

[jhrozek]

@Moisan we merged a commit that would only avoid pinning actions that reference main or master by default (although the behaviour is still configurable, including ignoring all branches). I was thinking about another commit that would do what you proposed - gather information about the actions we skip and why and presenting them to the user in the CLI.

[Moisan]

Thank you!

I was thinking about another commit that would do what you proposed - gather information about the actions we skip and why and presenting them to the user in the CLI.

Yes that would also be very useful.

[blkt]

Hey @Moisan I just wanted to check if this still relevant or if the solution provided is sufficient. If that's the case, would it be ok for you if we close this?

Regarding the additional behavior of skipping and reporting it to the user, we would love to look into a PR if you're interested to contributing.