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

[gopherbot]

Change https://go.dev/cl/614299 mentions this issue: internal/task: add release definition for vscode-go stable release

[gopherbot]

Change https://go.dev/cl/615215 mentions this issue: internal/task: add steps to build and publish package extension

[h9jiang]

Next CL, some improvement on error surfacing

Context: we execute the following cloudbuild steps in insider release flow:

1. download repo
2. checkout branch
3. build the package from the commit
4. copy the log from the build process to gcs

After that, in x/build, we read the log from gcs and show them.

Pain point: there is a dependency in this execution chain. If the package build is successful, we will copy the log from local to gcs and eventually surfaced to relui. But if the package build failed, the cloud build exited without continue to the log copying step.

So in the next CL, a few changes will be made to correctly surface both the success log and failure log to relui when executing RunCustomSteps

• CloudBuild log will be stored in both cloud logging and the gcs file. The log file under gcs is following a naming pattern of "log-${BUILD-ID}.txt".
• CloudBuild Completed method will return both the status detail and the log. The caller can decided whether he/she want to print the log or not.
• In vscode-go release flow, we will first print the log and then return the error to make sure the log will be available even the cloud build failed.

A local screenshot that pass the step:

A local screenshot that failed the step:

[gopherbot]

Change https://go.dev/cl/615595 mentions this issue: internal/task: surface script logs to relui even on script failure

[h9jiang]

Next CL, we add a few missing steps in vscode go stable release to create GitHub release as draft, and create a tag.

A small change on the process. Previously, the flow use tag to build the package extension but instead, it will start using commit. (It's the same thing).

The release here does not have source because this tag does not exist. :D

[gopherbot]

Change https://go.dev/cl/615596 mentions this issue: internal/task: create release tag and github release in vscode release

[h9jiang]

Next CL, we will update the package.json and package-lock.json in the master branch so it will point to the next stable version.

The local test below did not execute anything because the master branch has been updated.

When I provide a hard-coded version, the local test create the following CL to update the version to v0.48.0-dev.

[gopherbot]

Change https://go.dev/cl/615975 mentions this issue: internal/task: update package.json before vscode-go insider release

[gopherbot]

Change https://go.dev/cl/615977 mentions this issue: internal/task: remove unused log and improve on release note

[h9jiang]

Next CL, we will add a input parameter to both vscode-go and gopls release so the github issue will be correctly assigned to the coordinator.

[gopherbot]

Change https://go.dev/cl/616195 mentions this issue: internal/task: add release coordinator parameter

[h9jiang]

Next CL, we will update the package.json and package-lock.json in release branch. This step will be triggered for every prerelease flow.

If the package.json in release branch is already pointing to the correct version, no CL will be created.
If the package.json in release branch is pointing to the wrong version, an auto-submit CL will be created and waiting to be merged.

Once the CL merged, the flow will read the head of the release branch again. Pick that commit as release commit.

[gopherbot]

Change https://go.dev/cl/617157 mentions this issue: internal/task: update the package.json version after branch cut

[h9jiang]

Next CL, we will update the CHANGELOG.md in master branch after a stable minor version release.

When we are releasing v0.44.0, we should create a new heading "## v0.44.0" and move all the content under "## Unreleased" to "## v0.44.0".

[gopherbot]

Change https://go.dev/cl/617276 mentions this issue: internal/task: add new heading for stable minor release in change log

[gopherbot]

Change https://go.dev/cl/617477 mentions this issue: internal/task: include date in vscode-go github release note

[gopherbot]

Change https://go.dev/cl/618396 mentions this issue: internal/task: update the changelog for stable patch and insider release