Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify releases of the CodeQL Action using tags instead of branches #1033

Merged
merged 6 commits into from
Apr 25, 2022

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.

2 participants