ci: Automate some of the release process

[cameron-martin]

trafficstars

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. Additionally, new entries will be written in a slightly different format (example), 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.

[cameron-martin]

Some questions:

• Is it okay to use github actions for this, even though we use bazelci for building? I see we do have some actions running already (CodeQL).
• This requires a personal access token, added as a github secret (it can't use the default GH_TOKEN one since it doesn't have the necessary permissions). Do we already have a bot account for this? Maybe @bazel-io?

[cameron-martin]

I would love to have the automation generate and upload the vsix too. Could we have it create a draft release, and the update the testing instructions to say "download the vsix and test it; if all good then publish the draft release"?

Automatically uploading the vsix would be great, and release please can create draft releases. However, release please can only create this release after it's done a lot of the other release process, for example creating the release commit, adding a tag etc. There would be no way of sensibly backing out of this at this point if the testing determined that something was broken.

Without automated testing, I think the only sensible thing is to test before the release please PR is merged and the release process is kicked off.

[jfirebaugh]

Ah, true. I would also be okay with saying "test a built vsix first, then trigger the release" and having the release build and upload its own vsix. I don't think it's essential that the one attached to the release is the one that was built and tested locally (I think for marketplace publishing, @fweikert may build his own vsix rather than downloading the release attachment, such that there has never been a single source of truth anyway.)

[Zemnmez]

Anything I can help to do to get this merged? I notice release is quite a bit behind head now.

[cameron-martin]

The thing blocking it is obtaining credentials for the GitHub action.

[vogelsgesang]

This requires a personal access token, added as a github secret (it can't use the default GH_TOKEN one since it doesn't have the necessary permissions).

Which permissions is the GH_TOKEN missing? To my understanding, the contents: write should give us all the necessary permissions.

According to https://github.com/google-github-actions/release-please-action?tab=readme-ov-file#github-credentials, the major downside of using the GH_TOKEN is that the release PRs wouldn't trigger the normal pre-commit verification jobs.

All in all, I think this would still be a step in the right direction. I think it is acceptable to not have those checks on release PRs given that the changes in those PRs would primarily be version bumps and changelog adjustments

[cameron-martin]

Yeah, I think you are right. I'll merge this and see what happens.

[cameron-martin]

It looks like it is detecting past releases correctly: https://github.com/bazelbuild/vscode-bazel/actions/runs/8522624305/job/23343222392

Now we just need to wait for these to be a user-facing commit (either fix: or feat:), and see if it creates releases properly.

[cameron-martin]

The release PRs seem to fail due to github actions account not having the CLA signed. Any ideas how to resolve this?

[vogelsgesang]

@cameron-martin could you rerun the release-please job?

I updated the pull request description of #350 to include a COMMIT_OVERRIDE. If this gets picked up by release-please, I would go through all my other PRs and update them such that they properly show up in the changelog.

Maybe we want to add a pull_reqest: edited trigger (see docs), i.e.:

on:
  push:
    branches:
      - master
  pull_request:
    types: ["edited"]

to automatically pick up such changes? Not sure if this will work, though... I never tried it before...

[cameron-martin]

Looks like that worked. I wonder if running it on all PR edits is a bit of a waste of resources considering that this should be used infrequently and fixes itself after the next commit to master.

[vogelsgesang]

I just finished going through my previous pull requests to make sure they show up correctly in the release notes.

I think that #355 might still need a better release note, given that it might break users still using older Bazel versions. Currently, this is classified as a revert in the release notes which is a bit misleading. When I read release notes, I would not expect a revert to be a potentially breaking change.

Maybe something like

feat: Use a separate òutput_base` by default (#270)

BREAKING CHANGE: If you are still using a Bazel version <= 7.0, you should disable the queriesShareServer setting or add Bazel's convenience symlinks to your .bazelignore

would be better for users of the extension?

[vogelsgesang]

The release PRs seem to fail due to github actions account not having the CLA signed. Any ideas how to resolve this?

The README of https://github.com/google-github-actions/test-infra states

Additionally, there is an organization secret (accessible to all repos) ACTIONS_BOT_TOKEN which is a GitHub Personal Access Token for our GitHub Actions bot. This is largely for authoring commits, since the Google CLA cannot be signed by the GitHub Actions bot.

which sounds as if we would still need a PAT 😞

But on the bright side: The PR still provides value, in the worst case we can pull the commit and open a separate PR for it under the name of an actual person. At least until we have a PAT set up.

[cameron-martin]

I suspect that is just for the google-github-actions org, since I can't find any usages elsewhere. It'd be nice if we could use the @bazel-io account, but I don't know if any PATs for that account are available organisation-wide.

[cameron-martin]

I think that https://github.com/bazelbuild/vscode-bazel/pull/355 might still need a better release note, given that it might break users still using older Bazel versions.

Before the next release I'm planning on making this change not so breaking, so I'll leave fixing the release notes until then.

[vogelsgesang]

I suspect that is just for the google-github-actions org, since I can't find any usages elsewhere.

Agree. I was not referring to the ACTIONS_BOT_TOKEN but primarily to the sentence

This is largely for authoring commits, since the Google CLA cannot be signed by the GitHub Actions bot.

which rules out the alternative approach, i.e. letting the githubactions bot sign the CLA

[vogelsgesang]

I would also be okay with saying "test a built vsix first, then trigger the release" and having the release build and upload its own vsix

I took a stab at this in #364. With this change, as soon as a Github release gets created, the vsix gets automatically built and attached to the Github release. In addition, prebuilt .vsix packages are uploaded as part of the Github Action's artifacts for each commit on master and for each pull request