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

Update release manifest + QA #1008

Merged
merged 29 commits into from
Mar 22, 2024
Merged

Update release manifest + QA #1008

merged 29 commits into from
Mar 22, 2024

Conversation

jhchabran
Copy link
Contributor

@jhchabran jhchabran commented Mar 21, 2024

Add the final layer of paint + QA (internal+promotion).

I reworked how we handle branches, so we have the simplest and safest approach for the next few release cycles:

  • creating an internal release:
  • promoting a release:
    • internal/release-vX.Y.Z -> promote/release-vX.Y.Z
    • opens a PR (ex: (promote) release: build v5.3.666 #1020)
    • CI build
    • once it reaches the finalization step in CI:
      • create a branch from promote/release-vX.Y.Z to release-vX.Y.Z
      • it posts a message in the PR indicating that it's been publicly released and that PRs can be safely closed (on both the promotion PR and the public one)
      • tags the commit from the release-vX.Y.Z branch.

The previous flow was:

  • from any branch, sg release create ... would checkout a new branch named wip_vX.Y.Z
  • a PR is created, trigger a CI run for the internal release.
    • at the very end of the run, the finalize step would create a new branch named wip-release-vX.Y.Z
  • from any branch sg release promote-to-public would checkout a new branch named promote-release_vX.Y.Z
    • a PR is created, targeting wip-release-vX.Y.Z as the base branch, triggering a CI build for the promotion
      • there was a bug, you could end up accidentally creating a branch that can't be merged into that base. It works if you're running that command from the internal branch but may not otherwise.
      • at the very end of the run, the finalize step would tag the commit.

Problem: if you decide to merge the final branch that has the tagged commit, you'd end up with a dangling commit, which is risky/scary. This passed the review because back then we overlooked the fact that it's very to just close the PR, to keep things tidy.

Checklist

  • Sister deploy-sourcegraph change:
  • Sister customer-replica change (if necessary, for any changes affecting pure-docker or configuration):
  • All images have a valid tag and SHA256 sum

Test plan

image

CleanShot 2024-03-22 at 14 07 32@2x

CleanShot 2024-03-22 at 14 07 48@2x

@jhchabran
Copy link
Contributor Author

@@ -2,4 +2,5 @@ nodejs 16.7.0
yarn 1.22.4
shellcheck 0.7.1
golang 1.19.8
github-cli 2.46.0
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Needed to post on PRs. Tested in CI.

@jhchabran jhchabran changed the title Jh/qa/release Update release manifest + QA Mar 22, 2024
@jhchabran jhchabran marked this pull request as ready for review March 22, 2024 13:13
# Therefore, if you update them, or if you decide to change how we detect what kind of build we're dealing
# with, please update this file as well.
- label: "(internal) Release: test"
if: build.branch =~ /^internal\/release-.*/
Copy link
Contributor

Choose a reason for hiding this comment

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

What does =~ mean?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's the regexp operator

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