Skip to content

Conversation

@henrymercer
Copy link
Contributor

@henrymercer henrymercer commented Apr 14, 2022

We currently reference versions of the CodeQL Action (v1, v2) using branches and not tags. This is nice because it is more consistent with the intention of tags in Git. However it is problematic in terms of Dependabot: users on the v1 or v2 branches won't get Dependabot update PRs, as these are only generated for users on a specific tag or commit SHA.

This PR prepares us to specify releases of the CodeQL Action using tags instead of branches, which will mean our customers who have configured Dependabot for the Actions ecosystem configured will receive a Dependabot update from v1 to v2.

Commit-by-commit review recommended. I'd particularly appreciate a check that I haven't forgot to update any places that use the release branches (i.e. previously v1 and v2, now releases/v1 and releases/v2).

Deployment plan

  • Open a PR updating references to v1 and v2 to releases/v1 and releases/v2 respectively. This PR will also automatically update the v1 and v2 tags as part of future release processes. (This is that PR.)
  • Wait for this PR to be approved, but don't merge it
  • Create branch protection rules for releases/v1 and releases/v2
  • Create the v1 and v2 tags manually
  • Rename the v1 and v2 branches to releases/v1 and releases/v2 respectively
  • Merge the PR (we do this after renaming the branches so we don't trigger any workflows)

Example Dependabot update on a private repo backlinked for maintainers.

Merge / deployment checklist

  • Confirm this change is backwards compatible with existing workflows.
  • Confirm the readme has been updated if necessary.
  • Confirm the changelog has been updated if necessary.

@henrymercer henrymercer requested a review from a team as a code owner April 14, 2022 16:55
Copy link
Contributor

@aeisenberg aeisenberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great. I'm pretty sure you mentioned that it's not ready to be merged until later, but it looks good to be merged when that time comes.

@henrymercer
Copy link
Contributor Author

I intend to merge this after updating the v1 and v2 tags and renaming the release branches — see the "Deployment plan" section of the PR description if you missed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants