release: create a relui workflow for the vscode-go release process

[hyangah]

This issue tracks the relui workflow to further automate the vscode-go release process. The new relui-based release process includes

• Sanity check on the version

• Stable release: the initial version will simply migrate the existing release process. But the final version will handle:

  • Create an issue to track the release
  • Create a new release branch (for v0.M.0) from the chosen prerelease version.
  • Create CLs for cherry-pick (for v0.M.N where N > 0).
  • Create a CL to update the version in package.json and package-lock.json.
  • Create a CL to add/update extension/LICENSE file. (not the top-level LICENSE file).
  • Tag the release candidate.
  • Wait for the operator's manual testing with RC.
  • Trigger the next prerelease for v0.(M+1).0.
  • Tag the final release.

• Prerelease (to be added with golang/vscode-go#1935)

  • Work with the master branch (no new branch creation)
  • Create a CL to update the version in package.json and package-lock.json.
  • Skip processes like issue/milestone creation.

cc @h9jiang

[h9jiang]

As the first CL, we will create a new workflow which is responsible of creating a release candidate for the stable version of vscode-go extension.

The input version should be the next version of some existing versions. The input version has to be a stable version. The input version's pre-release label should be empty. (The flow will figure out which rc it will pick)

[gopherbot]

Change https://go.dev/cl/607176 mentions this issue: internal/task: add new workflow for vscode-go pre-release

[h9jiang]

Some offline sync with Hana and Dmitri, we want to adopt the approve functionality same as gopls release automation. And also use the cool drop down menu.

The input of the release will be simplifies as below, the coordinator only need to provide what kind of version he/she want to release. Right now, it can only be next minor or next patch.

The flow will figure out the version based on the user input, the local relui below, I choose next minor. The relui return v0.44.0-rc.1 WAI.

Some more explanation, right now, the latest release is vscode-go is v0.42.0. The next stable version should be v0.44.0 because 0.43 will be a insider version.

The local relui below, I choose next patch., the relui return v0.42.1-rc.1. The next patch version is v0.42.1 and the pre-release version start with rc.1. (because there is no other rc available)

@hyangah @dmitshur

And the same input will be applied to gopls release as well, the coordinator will no longer need to put the version string. The screenshot in this comment should give you an earlier taste what will be coming in gopls. @findleyr

[h9jiang]

The next CL, we will add a step in gopls release process. Every gopls release will trigger a gopls version update in vscode-go repo.

The update will happen at the last step of gopls release & gopls pre-release.

[gopherbot]

Change https://go.dev/cl/608416 mentions this issue: internal/task: add step to update gopls version in vscode-go project

[h9jiang]

Next CL, the flow will create the release milestone and release issue. (only if there isn't one already created and open)

The first run of the flow create this release issue below and add it to the release milestone.

The second time, it realize there is an existing & open issue, so it will not create this issue again.

[gopherbot]

Change https://go.dev/cl/608417 mentions this issue: internal/task: reuse or create release milestone and issue

[h9jiang]

Next CL, the vscode go release flow will try to create a release branch if not already exist.

The current logic is, only create a branch if the input version is minor version and it's the first candidate of that minor release. in form of vX.Y.0-rc.1

The local relui failed for next minor release to create the branch because of permission issue. (the input to this step is v0.44.0-rc.1) WAI

The local relui failed for next patch release. The flow try to release v0.42.1-rc.1 but this branch release-v0.42 does not exist. Based on the implementation it's working as intended. But we will need to figure out how to do v0.42.1+ release because this is in a transit period. Between single release branch model and multi release branch model.

@hyangah a quick work around is, we cut a branch release-v0.42 manually from the current head of release branch. Or we can embed some hard coded logic in release flow, ask the flow to refer to release branch when the input version is lower than or equals to v0.42

Regardless of the final solution, we can move forward with the CL review while working on this back-ward compatibility issue.

[gopherbot]

Change https://go.dev/cl/608817 mentions this issue: internal/task: create the branch for the first rc in minor release

[hyangah]

@h9jiang Now there is release-v0.42 cut from the current release branch. So you can work/experiment with it.

[gopherbot]

Change https://go.dev/cl/609177 mentions this issue: project.config: grant relui access to create vscod-go release branches

[gopherbot]

Change https://go.dev/cl/609315 mentions this issue: project.config: grant relui access to create vscod-go release branches

[gopherbot]

Change https://go.dev/cl/609376 mentions this issue: internal/task: avoid updating gopls version in vscode-go release branch

[h9jiang]

Next CL, we will add a step in gopls release flow to update gopls version in vscode-go project.

After a gopls release is done, both master branch and release branch will be updated.

SCREENSHOT: the local relui want to update the gopls version in both master and release branch. Because the gopls 0.16.2 is not yet released, the master branch have nothing to update (already up-to-date), the release branch have a CL ongoing.

When running this in production, what we will be expecting is, both master and release branch will be updated at the same time because production flow will release 0.16.2. So the master branch will then out-dated.

[gopherbot]

Change https://go.dev/cl/610539 mentions this issue: internal/task: update the gopls version in vscode-go project

[gopherbot]

Change https://go.dev/cl/612115 mentions this issue: internal/task: add a step to tag the release candidate

[h9jiang]

Next Change, we will add a new flow for vscode-go insider version release

When choosing this flow, this flow will figure out which insider version you should release. In the local relui run, the relui analyze the current tags in vscode-go repo and figure out the next insider version is v0.43.2

[gopherbot]

Change https://go.dev/cl/611940 mentions this issue: internal/task: add insider release flow and determine insider version

[h9jiang]

Next Change, we will add two steps in insider version release

1. Read the head commit from master branch
2. Wait for coordinator approval.

Personally speaking, releasing from master branch is a kind of a risky move because there could be commit merged anytime. So I explicit the commit upon approval.

[gopherbot]

Change https://go.dev/cl/611917 mentions this issue: internal/task: read the head commit of master branch and await approval

[h9jiang]

The next CL, we will refactor the x/build so it can run cloud build using docker based image. This docker based cloud build will be used to trigger vscode-go test. This test is our final signal indicating whether the commit is healthy or not.

[gopherbot]

Change https://go.dev/cl/610375 mentions this issue: internal/task: add a step to run test for vscode-go extension

[gopherbot]

Change https://go.dev/cl/612815 mentions this issue: extension/tools/release: skip version check for package creation

[gopherbot]

Change https://go.dev/cl/611845 mentions this issue: extension/tools/release: skip version check for package creation

[h9jiang]

Next Change, with the extended functionality from relui, we will add a step to generate the vscode extension package

This step will use npx vsce ..... to create artifacts for this vscode-go version. The generated package will be copied to a gcs bucket for further usage.

Only the npm ci & npx vsce command's log will be printed to terminal for reference.

[gopherbot]

Change https://go.dev/cl/611945 mentions this issue: internal/task: generate release artifacts in vscode-go prerelease

[gopherbot]

Change https://go.dev/cl/613079 mentions this issue: extension/tools/release: clean up temporarily created README.md

[h9jiang]

Next change, we will use relui to create release note as draft for vscode-go release coordinator for review.

From the relui, the relui will print the url to the draft release note so the coordinator can review and publish.

In my local test, I did change the order of the step execution so I can test it locally.

After preparing the release note as draft, should we prepare a approve button where the coordinator can approve and the release ui will publish the draft release and make it official release candidate?

Or you think it's ok to release the rc release note without coordinator approval?

@hyangah

[gopherbot]

Change https://go.dev/cl/613595 mentions this issue: internal/task: add a step to create github release as draft

[gopherbot]

Change https://go.dev/cl/613597 mentions this issue: internal/task: fix a bug where RunCustomSteps return without result url