Closed hyangah closed 6 days ago
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)
Change https://go.dev/cl/607176 mentions this issue: internal/task: add new workflow for vscode-go pre-release
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
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.
Change https://go.dev/cl/608416 mentions this issue: internal/task: add step to update gopls version in vscode-go project
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.
Change https://go.dev/cl/608417 mentions this issue: internal/task: reuse or create release milestone and issue
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.
Change https://go.dev/cl/608817 mentions this issue: internal/task: create the branch for the first rc in minor release
@h9jiang Now there is release-v0.42
cut from the current release
branch. So you can work/experiment with it.
Change https://go.dev/cl/609177 mentions this issue: project.config: grant relui access to create vscod-go release branches
Change https://go.dev/cl/609315 mentions this issue: project.config: grant relui access to create vscod-go release branches
Change https://go.dev/cl/609376 mentions this issue: internal/task: avoid updating gopls version in vscode-go release branch
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.
Change https://go.dev/cl/610539 mentions this issue: internal/task: update the gopls version in vscode-go project
Change https://go.dev/cl/612115 mentions this issue: internal/task: add a step to tag the release candidate
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
Change https://go.dev/cl/611940 mentions this issue: internal/task: add insider release flow and determine insider version
Next Change, we will add two steps in insider version release
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.
Change https://go.dev/cl/611917 mentions this issue: internal/task: read the head commit of master branch and await approval
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.
Change https://go.dev/cl/610375 mentions this issue: internal/task: add a step to run test for vscode-go extension
Change https://go.dev/cl/612815 mentions this issue: extension/tools/release: skip version check for package creation
Change https://go.dev/cl/611845 mentions this issue: extension/tools/release: skip version check for package creation
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.
Change https://go.dev/cl/611945 mentions this issue: internal/task: generate release artifacts in vscode-go prerelease
Change https://go.dev/cl/613079 mentions this issue: extension/tools/release: clean up temporarily created README.md
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
Change https://go.dev/cl/613595 mentions this issue: internal/task: add a step to create github release as draft
Change https://go.dev/cl/613597 mentions this issue: internal/task: fix a bug where RunCustomSteps return without result url
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
Change https://go.dev/cl/613596 mentions this issue: [DNR]internal/task: upload generated package extension to release asset
Change https://go.dev/cl/613598 mentions this issue: internal/task: fix a bug showing diff against insider version
Change https://go.dev/cl/613598 mentions this issue: internal/task: fix a bug to show diff against last stable version
Change https://go.dev/cl/613599 mentions this issue: internal/task: add a step to mail announcement for vscode prerelease
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
Change https://go.dev/cl/614216 mentions this issue: internal/task: add steps to vscode-go insider release flow
Next change: a few more steps will be added to vscode-go insider flow.
Including:
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:
## Unreleased
is empty.
v0.43.1
in my local test. The relui execution:
Change https://go.dev/cl/614335 mentions this issue: extension/tools/release: remove tool requirement of jq, git, gh
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
Change https://go.dev/cl/614455 mentions this issue: [DO NOT REVIEW]internal/task: add a step to publish packaged extension
Change https://go.dev/cl/614718 mentions this issue: internal/task: add step to mail announcement in insider release
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.
Change https://go.dev/cl/614299 mentions this issue: internal/task: add release definition for vscode-go stable release
Change https://go.dev/cl/615215 mentions this issue: internal/task: add steps to build and publish package extension
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
A local screenshot that pass the step:
A local screenshot that failed the step:
Change https://go.dev/cl/615595 mentions this issue: internal/task: surface script logs to relui even on script failure
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
Change https://go.dev/cl/615596 mentions this issue: internal/task: create release tag and github release in vscode release
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.
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:
package.json
andpackage-lock.json
.extension/LICENSE
file. (not the top-level LICENSE file).v0.(M+1).0
.Prerelease (to be added with golang/vscode-go#1935)
package.json
andpackage-lock.json
.cc @h9jiang