Hi all, On 17.04.2026 16:59, Alex Herbert wrote: > On Fri, 17 Apr 2026 at 15:41, Gary Gregory <[email protected]> wrote: >>> The example of how to use this workflow is: >>> >>> uses: >>> >> apache/commons-parent/.github/workflows/codeql-analysis-reusable.yml@master >>> >>> The pin is not to a specific version but to the master branch. >> >> That's even worse: How does this provide anything deterministic? We >> want more precision, not less. >> > > How is a release determined for a github action? If this is to simply add a > tag to the repo then the release process will not be time consuming, but > updating all the child projects with specific pins will be. > > If you want to have specific pinned versions for each repository then this > change will not change maintenance of the child projects.
You can pin a reusable workflow to *any* Git reference or a SHA1. In this case I would propose to pin it to `master` and always use the latest version for each new workflow. Is it deterministic? Yes, once you merge a PR in `commons-parent` all new jobs in the other repositories will download the new version. > But this is for actions that are not particularly dependent on the build of > the code. I do not see why pinning versions of codeql or scorecards > analysis is necessary. For functional reasons pinning is not necessary: I don't expect any errors to occur after an upgrade. It is however important to pin them for security reasons, not so much for CodeQL and Dependency Review (they are GitHub-owned and you could trust GitHub as a monolith), but certainly Scorecards. For CodeQL and Dependency Review we can reduce the upgrade churn in two ways: 1. Pin to GitHub-controlled version tags. This is what I proposed for Log4j in: https://github.com/apache/logging-parent/pull/457 2. Pin to a branch of a repository we control. This is what I am proposing here: we trust each individual committer not to lose their access token. > Are they likely to fail, and if they do, does it matter? Priority is > to ensure the main maven build is always OK to allow PR > integration. But if codeql stops working then it can wait for a fix > in the master. They are unlikely to fail, although it is important to wait for the results of CodeQL in case a PR has some security problems we missed. > A trial of this could use a status page that collects the build success of > all child projects using the same workflow. That is a good idea: we could add status badges for all downstream repositories to see which ones fail. > Also, is there a way for a child workflow to request it be run if > the non-specific pin it is using is updated? This would allow issues > to be identified sooner. Not directly: it is not easy to trigger a workflow in another repo. However you can modify the `codeql-analysis` workflow in Commons Parent, so it can: - Be triggered manually, - Download a different repo to analyze. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
