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

[h9jiang]

Next change, we will upload the previously generated package extension to the github release as a release asset.

by default, when we are creating a release using tag, it have two asset automatically (source code zip & source code tar.gz). The relui will upload one more asset go-X.Y.Z-Pre.vsix resulting in 3 assets in the release.

The updated release looks like this:

NOTE: in order to test this locally, I will have to create a github release for a tagged version (I picked v0.42.0-rc.1) because my personal credential do not have permission to create a new tag (which is WAI). In addition, I have to hardcoded some logic by telling the steps to create package extension using a pre-defined commit (pretending we are building the package for v0.42.0-rc.1 but the commit is head of the master branch). But I believe the logic will be very similar in production so we should not worry too much. :D

[gopherbot]

Change https://go.dev/cl/613596 mentions this issue: [DNR]internal/task: upload generated package extension to release asset

[gopherbot]

Change https://go.dev/cl/613598 mentions this issue: internal/task: fix a bug showing diff against insider version

[gopherbot]

Change https://go.dev/cl/613598 mentions this issue: internal/task: fix a bug to show diff against last stable version

[gopherbot]

Change https://go.dev/cl/613599 mentions this issue: internal/task: add a step to mail announcement for vscode prerelease

[h9jiang]

E2E local test for prerelease flow.

I have to make some change to the flow to make sure it can success finish. The change is available in

https://go-review.git.corp.google.com/c/build/+/613162

@hyangah

[gopherbot]

Change https://go.dev/cl/614216 mentions this issue: internal/task: add steps to vscode-go insider release flow

[h9jiang]

Next change: a few more steps will be added to vscode-go insider flow.

Including:

• Verify the commit in the master branch.
• Generate package extension based on the commit.
• Add the insider tag to the commit.
• Create GitHub release with the tag, diff and body.

A local test, after the local run finished, a new github release (draft) is created. This draft is meant for insider version v0.43.2 because we already released v0.43.1.

Things to mention:

• The diff is between v0.42.0-rc.1 and v0.43.2 because v0.42.0-rc.1 is the last time we did the branch cut.
• The diff link does not work because I do not have permission to tag v0.43.2 (this tag will be skipped)
• The milestone of this insider release is v0.44.0 because the insider release do not have milestone and what is available in insider is what will be available in next release.
• The content of github release is empty because CHANGELOG.md's ## Unreleased is empty.
  • The release is based on tag v0.43.1 because I do not have permission to tag v0.43.2 so I hard coded v0.43.1 in my local test.

The relui execution:

[gopherbot]

Change https://go.dev/cl/614335 mentions this issue: extension/tools/release: remove tool requirement of jq, git, gh

[h9jiang]

Next change, we add a new step to vscode-go to publish the packaged extension to vscode market place.

In my local relui test, I create a fake secret called FAKE_TOKEN and export the token as env VSCE_PAT in the publish step. (vsce is going to read this env and use that as credential to publish the extension)

Because my credential is fake, so the publish did not go through and failed because not authorized to access this resource

[gopherbot]

Change https://go.dev/cl/614455 mentions this issue: [DO NOT REVIEW]internal/task: add a step to publish packaged extension

[gopherbot]

Change https://go.dev/cl/614718 mentions this issue: internal/task: add step to mail announcement in insider release

[h9jiang]

Next CL, we will add the last flow vscode-go stable version release flow. The goal of this flow is to release a release candidate as final release. (release v0.44.2-rc.3 as v0.44.2)

The flow will take the same input parameter, a version bump strategy which will be used to determine which version you are trying to release (next patch resulting in v0.42.2). Then the flow will find the latest rc of that release. (for example, the flow will find v0.42.2-rc.3 based on the input of v0.42.2)

However, in my local run, there is no ongoing release, so they all failed because there is no release candidate available.

[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.