build(deps): bump gradle-update/update-gradle-wrapper-action from 1 to 2 #17078
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [gradle-update/update-gradle-wrapper-action](https://github.com/gradle-update/update-gradle-wrapper-action) from 1 to 2. - [Release notes](https://github.com/gradle-update/update-gradle-wrapper-action/releases) - [Changelog](https://github.com/gradle-update/update-gradle-wrapper-action/blob/main/CHANGELOG.md) - [Commits](gradle-update/update-gradle-wrapper-action@v1...v2) --- updated-dependencies: - dependency-name: gradle-update/update-gradle-wrapper-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
dependencies
There was a problem hiding this comment.
v2.0.0? v2 is a separate tag
https://github.com/gradle-update/update-gradle-wrapper-action/tags
Changes look good:
https://github.com/gradle-update/update-gradle-wrapper-action/blob/main/CHANGELOG.md#v200
Added input parameter pr-title-template, by @paulschuberth
Added input parameter commit-message-template, by @paulschuberth
Added input parameter distributions-base-url, by @yeikel
Updated action to run with Node 20, by @chadlwilson
Updated action dependencies.
There was a problem hiding this comment.
I've published an action before and the tagging is annoying.
You want to tag on a specific release, but the way you specify actions normally in workflows is with a major-version only so that you get updates without having to process updates all the time.
So, what you do as an action maintainer is you maintain a major-version tag, and you tag every specific version, and with every release you slide/move the major-version tag to the new patch release. Which is kind of lame, but there you go
So this seems normal to me, for the way the github actions ecosystem works
dependabot
bot
deleted the
dependabot/github_actions/gradle-update/update-gradle-wrapper-action-2
branch
|
From a security perspective: does this mean that we're not pinned to a specific version, and the action can be updated outside dependabot? |
Yes, the github action in use in any specific workflow run will be dereferenced from whatever the tag on the foreign repo is. If they slide the tag, then you get a new SHA under the tag and new software. Note, that if you specified specific tags (not a sliding semver-major tag) they could still move that tag in the repo. If you rely on a foreign repo, it can always move on you, unless you rely on a specific SHA I suppose. Which sounds...like a hassle in the "security vs usability" tradeoff. I'm inclined to trust this specific foreign repo is run well and won't cause some random thing to happen in our repo. And the tokens we allow in the workflows are constrained so they can't persist bad things if I understand correctly |
Bumps gradle-update/update-gradle-wrapper-action from 1 to 2.
Release notes
Sourced from gradle-update/update-gradle-wrapper-action's releases.
... (truncated)
Changelog
Sourced from gradle-update/update-gradle-wrapper-action's changelog.
Commits
9268373Update changelog for v2.0.0 (#827)b1f73fdAdd distributions-base-url input to README.md (#829)7546413action.yml: run on node20 (#828)e36e57aMerge branch 'yeikel-custom/url'c5657a0Merge branch 'custom/url' of github.com:yeikel/update-gradle-wrapper-action i...adc4884Bump@actions/globfrom 0.4.0 to 0.5.0 (#826)e0054daBump eslint-plugin-import from 2.29.1 to 2.30.0 (#825)50f2699Bump@actions/http-clientfrom 2.1.1 to 2.2.3 (#814)d0445b1Bump typescript from 5.4.5 to 5.6.2 (#822)13be621Customize commit messages (#679)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)