Open
Description
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
Metadata
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
rdimitrov commentedon Jul 15, 2024
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 commentedon Jul 15, 2024
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 ismyaction@master
).This is configurable, e.g. with a config like this:
stored in
.frizbee.yml
the action can be resolved:I am not sure if dependabot would update the action though, this needs some more testing.
jhrozek commentedon Jul 15, 2024
The other option would be to modify the workflow to use a tag in the first place:
then frizbee should be able to pin the action and put the magic comment in that helps dependabot to upgrade the action.
Moisan commentedon Jul 15, 2024
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.
Only ignore main and master, not all branches when pinning actions
jhrozek commentedon Jul 17, 2024
@Moisan we merged a commit that would only avoid pinning actions that reference
main
ormaster
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 commentedon Jul 18, 2024
Thank you!
Yes that would also be very useful.
blkt commentedon Oct 29, 2024
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.