Due to it being the only option other than using an unstable version from the branch tip, the workflow does a full pin of the action version, meaning that the workflow must be updated after every new release of the action (e.g., https://github.com/arduino/arduino-cli/pull/1601).
Use of the major version ref will cause the workflow to use a stable version of the action, while also benefiting from ongoing development to the action up until such time as a new major release of an action is made. At that time we would need to evaluate whether any changes to the workflow are required by the breaking change that triggered the major release before manually updating the major ref (e.g., uses: carlosperate/download-file-action@v2). I think this approach strikes the right balance between stability and maintainability for these workflows.
Please check if the PR fulfills these requirements
[x] The PR has no duplicates (please search among the Pull Requests before creating one)
[x] The PR follows our contributing guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ]
UPGRADING.mdhas been updated with a migration guide (for breaking changes)What kind of change does this PR introduce?
Infrastructure enhancement.
What is the current behavior?
The
carlosperate/download-file-actionaction is used in the "Sync Labels" GitHub Actions workflow as a convenient way to download external resources.Due to it being the only option other than using an unstable version from the branch tip, the workflow does a full pin of the action version, meaning that the workflow must be updated after every new release of the action (e.g., https://github.com/arduino/arduino-cli/pull/1601).
A major version ref has been added to that repository: https://github.com/carlosperate/download-file-action/releases/tag/v1 It will always point to the latest release of the "1" major version series. This means it is no longer necessary to do a full pin of the action version in use as before.
Use of the major version ref will cause the workflow to use a stable version of the action, while also benefiting from ongoing development to the action up until such time as a new major release of an action is made. At that time we would need to evaluate whether any changes to the workflow are required by the breaking change that triggered the major release before manually updating the major ref (e.g., uses:
carlosperate/download-file-action@v2). I think this approach strikes the right balance between stability and maintainability for these workflows.No breaking change