ci: Automate some of the release process (#336)

This adds a github action to run release please. This automates a significant portion of the release process, including tagging, updating version numbers, changelog generation and creating github releases.

Notes:

* This requires changing the changelog format a bit, since release please looks for a [certain regex](https://github.com/googleapis/release-please/blob/72b0ab360c3d6635397e8b02f4d3f9f53932e23c/src/updaters/changelog.ts#L22). Additionally, new entries will be written in a slightly different format ([example](https://github.com/googleapis/release-please/blob/main/CHANGELOG.md)), but we can update the old changelog entries if necessary to make them consistent. This isn't easily customisable by the looks of it.
* This will require using the conventional commits format for commits. This is pretty lightweight though, and mainly comes down to appending either `fix:`, `feat:` or similar to the commit title.
* The format of tags will have to be changed to append a `v` to the start, since release please looks at these to determine the last release version.
* This does not automate uploading of the vsix, although it could fairly easily be modified to. However, until we have automated testing of this I don't think it adds much value, since it still has to be manually built for testing purposes.

.github/workflows/release-please.yml

@@ -0,0 +1,19 @@
+on:
+  push:
+    branches:
+      - master
+
+permissions:
+  contents: write
+  pull-requests: write
+
+name: release-please
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: google-github-actions/release-please-action@v4
+        id: release
+        with:
+          release-type: node

CHANGELOG.md

@@ -1,6 +1,6 @@
 # Change Log
 
-## Version 0.9.0 (February 20, 2024)
+## 0.9.0 (February 20, 2024)
 
 ### New Features
 
@@ -11,7 +11,7 @@
 
 - Make queries share the same server by default (@limdor)
 
-## Version 0.8.1 (January 2, 2024)
+## 0.8.1 (January 2, 2024)
 
 ### Bug Fixes
 
@@ -23,7 +23,7 @@
 - Migrate to eslint (@hypdeb)
 - Upgrade typescript (@cameron-martin)
 
-## Version 0.8.0 (December 15, 2023)
+## 0.8.0 (December 15, 2023)
 
 ### New Features
 
@@ -51,7 +51,7 @@
 - Optimized performance of `bazel query` operations (@iamricard)
 - CI updated to Node 20 (@jfirebaugh)
 
-## Version 0.7.0 (December 6, 2022)
+## 0.7.0 (December 6, 2022)
 
 ### New Features
 
@@ -80,7 +80,7 @@
           }
       ]
 
-## Version 0.6.0 (September 14, 2022)
+## 0.6.0 (September 14, 2022)
 
 ### New Features
 
@@ -105,7 +105,7 @@
 
 - return `default` for .sky files in getBuildifierFileType (@arahatashun)
 
-## Version 0.5.0 (October 29, 2021)
+## 0.5.0 (October 29, 2021)
 
 ### New Features
 
@@ -122,13 +122,13 @@
 
 We would like to thank Alex Frasson, Chi Wang, ericisko, hensom, Jonathan Dierksen and Neil Ding for their great contributions.
 
-## Version 0.4.1 (April 14, 2021)
+## 0.4.1 (April 14, 2021)
 
 ### Bug Fixes
 
 - Fix CVE-2021-22539: Malicious project can cause vscode-bazel to run arbitrary executable when linting a \*.bzl file.
 
-## Version 0.4.0 (August 21, 2020)
+## 0.4.0 (August 21, 2020)
 
 ### New Features
 
@@ -139,7 +139,7 @@ We would like to thank Alex Frasson, Chi Wang, ericisko, hensom, Jonathan Dierks
 - WORKSPACE.bazel files are now properly recognized.
 - We made multiple improvements to Windows support.
 
-## Version 0.3.0 (September 19, 2019)
+## 0.3.0 (September 19, 2019)
 
 ### Breaking Changes
 
@@ -162,7 +162,7 @@ We would like to thank Alex Frasson, Chi Wang, ericisko, hensom, Jonathan Dierks
 - BUILD files named `BUILD.bazel` are now correctly treated as BUILD files,
   not `bzl` files, for the purposes of formatting and linting.
 
-## Version 0.2.0 (May 15, 2019)
+## 0.2.0 (May 15, 2019)
 
 ### New Features
 
@@ -190,7 +190,7 @@ We would like to thank Alex Frasson, Chi Wang, ericisko, hensom, Jonathan Dierks
 - Fixed issue where VS Code would hang when the Bazel Build Targets view was
   opened and a workspace folder was _not_ part of a Bazel workspace.
 
-## Version 0.1.0 (January 23, 2019)
+## 0.1.0 (January 23, 2019)
 
 ### New Features
 
@@ -215,10 +215,10 @@ We would like to thank Alex Frasson, Chi Wang, ericisko, hensom, Jonathan Dierks
   is now presented that allows the user to type or select which target should
   be built or tested.
 
-## Version 0.0.2 (November 28, 2018)
+## 0.0.2 (November 28, 2018)
 
 - Fix an issue where runtime dependencies were listed as development dependencies.
 
-## Version 0.0.1 (November 28, 2018)
+## 0.0.1 (November 28, 2018)
 
 - Initial release.

RELEASE.md

@@ -1,30 +1,18 @@
-# One-Time Setup
+# Releasing
+
+Most of the releasing is done by [release please](https://github.com/googleapis/release-please), but there are still some manual steps required.
+
+## One-Time Setup
 
 Make sure you have the `vsce` tool installed:
 
 ```
 $ npm install -g vsce
 ```
 
-# Prepare a Release
-
-Once you have the code in the state that you want to release, make sure you've done the following:
-
-- Bump the version number in the `version` key of `package.json`.
-- Add a new section to CHANGELOG.md denoting the new release and any updates you wish to call out. This content is presented to users in the VS Code Extensions UI.
-- Tag the commit with the version number of the release:
-
-  ```
-  $ git tag x.y.z
-  ```
+## Create and Test the .vsix Package
 
-  (This step is optional; you can also do it as part of the GitHub release. See below.)
-
-- Push these changes (including the tag) to GitHub.
-
-# Create and Test the .vsix Package
-
-From the directory containing the extension source code, run the following command:
+Check out the branch of the auto-generated release PR and, run the following command from the directory of the extension source code:
 
 ```
 $ vsce package
@@ -44,21 +32,13 @@ Having this standalone package available before uploading the release to the Mar
 
 Once you're confident that the release works, deploy it using the steps below.
 
-# Deploy the Release
+## Deploy the Release
+
+To deploy the release, merge the auto-generated release PR. This will contain a changelog and version bump. Upon merging, this will create a github release & git tag. However, there are still some manual steps required to deploy the extension.
 
 We deploy the extension to **two** destinations:
 
-1. We create a .vsix package to upload as a GitHub release, since this is a useful archiving method and it allows users to download and roll back to a previous version of the plugin if necessary. This can be done by anyone who is a maintainer on GitHub.
+1. We create a .vsix package to upload as a GitHub release, since this is a useful archiving method and it allows users to download and roll back to a previous version of the plugin if necessary. This can be done by anyone who is a maintainer on GitHub. This is done by attaching the `vscode-bazel-x.y.z.vsix` file to the auto-generated release by dragging it or selecting it in the upload box.
 2. We publish the extension to the Visual Studio Marketplace so that it can be found in search results and downloaded from Visual Studio Code's Extensions area. This requires publishing rights for the Bazel organization on the Visual Studio Marketplace. Florian Weikert <fwe@google.com> has handled recent versions.
 
-# Creating a GitHub Release
-
-1. On the vscode-bazel Releases page, select **Draft a New Release**.
-2. Fill out the form as follows:
-   1. **Tag version**: Enter the version number of the release (in the format `x.y.z`). If you create this tag earlier (see Preparing a Release, above), that tag will be used; otherwise, it will be created for you.
-   2. **Release title**: Enter the version number and release date (for example, `x.y.z (November 28, 2018)`).
-   3. **Describe this release**: Paste the information you wrote about this version from CHANGELOG.md into this text area.
-3. Attach the `vscode-bazel-x.y.z.vsix` file to the release by dragging it or selecting it in the upload box.
-4. Once you're ready for it to be public, click **Publish release**.
-
 You can now delete the .vsix file if you wish; it will not be used when publishing to the marketplace.