GeezerVison

On main, we currently have a workflow generated from pr-checks/checks that uses an older version of actions/download-artifact than other workflows in the repo. This likely happened because the PR which introduced the relevant workflow (unsupported-macos.yml) was worked on while a Dependabot PR which updated actions/download-artifact was merged. Consequently, the version of actions/download-artifact used on the PR branch fell behind. When this was subsequently merged, the versions of actions/download-artifact on main become inconsistent.

This is generally not a problem and will be rectified by Dependabot next time it runs, with the exception of the sync-back.ts script that's run as part of the "Rebuild" workflow. It incorrectly assumes that all versions of actions in the repo are always consistent because it only expects to run on Dependabot PRs where all versions of a given action have been aligned. This is not the case if the inconsistency exists on main and Dependabot is not updating the relevant action. See e.g. #4289 which bumps a JS dependency, but ends up with workflow changes because of the inconsistency on main and the broken assumption in sync-back.ts.

This PR modifies sync-back.ts so that versions are tracked by workflow and only the versions found for a given generated workflow file are written to the corresponding specification. For the version written to sync.ts, we arbitrarily pick one if there are multiple (similar to the previous behaviour, although it may not be the same arbitrary one) and emit a warning.

Alternatives considered

Ideally, we'd not end up with inconsistencies on main in the first place, but that would require us to validate that all used actions have the same version in e.g. a merge commit for main before actually merging it or otherwise compare the versions to those on main in the merge queue. Since it's not fundamentally a problem, rarely happens, and will automatically be resolved by Dependabot after a week or so, I think the solution implemented here is acceptable however.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Environments:

• Testing/None - This change does not impact any CodeQL workflows in production.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).
• Other - Please provide details. Tested locally.

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Development/testing only - This change cannot cause any failures in production.

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.