chore(master): release 0.11.0

[github-actions]

🤖 I have created a release beep boop

0.11.0 (2024-11-28)

Features

• Cmd-click to jump to a source file from a build rule (#380) (fa38d08)
• codelens: Add a copy target command (da62c67)
• codelens: Don't add target names for one line targets (#407) (4f02dc5)
• codelens: Extend CodeLens to build and run more targets (00d9971)
• coverage: Basic test coverage support (#366) (0d293b8)
• coverage: Demangling C++ & Rust function names in coverage results (#398) (d28c294)
• coverage: Demangling of Java function names in coverage results (#388) (7084368)
• coverage: Load branch coverage from coverage files #389 (e5c95e4)
• lsp: Add option to trace LSP communication (#425) (583fb65)
• syntax highlighting for .bazelrc (#379) (2aea27e), closes #259

Bug Fixes

• buildifier: Handle relative buildifier path without warning #387 (60051c5)
• Change explorer UI label to "Bazel Targets" (#409) (dba3102)
• codelens: Apply commandArgs to run targets (#408) (9c77c18)
• coverage: Do not emit error on BRDA:0 entries (#417) (7f62f0e)
• coverage: Expand external local repo in coverage report (#418) (c115a86)
• Default to Python syntax highlighting theme (#397) (2614f19)
• Link the full label / file name instead of individual components (#382) (2e207c9)

---

This PR was generated with Release Please. See documentation.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[hofbi]

@vogelsgesang Is there any plan for when the next release will be made?

[vogelsgesang]

no, we don't have a specific plan, yet.

We are still in an in-between state of transferring ownership of this project from Google to the open-source community. We rely on people from Google to publish the extension to the Marketplace, and this process is a bit cumbersome. And I was hoping that we could first finish the transfer of ownership to the open-source community before cutting the next release.

Do you need an updated release for some reason? In case you only need a version for your own, local usage: Our Github actions actually include .vsix packages (see, e.g., here) which you can install in VS Code

[hofbi]

No urgent need for a new release, just wanted to check in

[rma-stripe]

We've received a few user complaints about the (small) bug that #387 addresses. Similar to hofbi, we are also not urgently in need of release, but an eventual release would be appreciated.

[adam-azarchs]

I think there's basically two problems here:

1. github actions hasn't signed the CAL, which is making that check fail. I don't know but maybe that check can be removed after this moves to contrib.
2. Even if this release were to be tagged, someone still needs to publish it to the marketplace. I'm not sure who that would be; IIRC there's basically one googler with the rights for that and I'm not sure they're still actively engaged with this project. I think changing that is also gated on moving this to contrib. Ideally we'd have a GitHub action that would, when a release is tagged, build the new .vsix, attest its provenance, and publish it to the marketplace. That would require it having credentials to do that¹, which in turn probably requires that it be published to an ADO org that isn't formally affiliated with Google.

Footnotes

1. Ideally it would get those via OIDC (e.g. azure/login) rather than using a token stored in github secrets, because a token stored in github secrets requires someone with the rights to generate a token remember to do that periodically. OIDC, by contrast, is essentially saying "this specific workflow from this specific repository is allowed to have permissions to do this thing", and Azure DevOps is trusting GitHub to honestly report which workflow is requesting a token. Then it's up to GitHub to keep their SSL cert valid, which I think we can rely on them doing. However, while Azure obviously supports OIDC login from GitHub, I'm not sure whether Azure DevOps in particular (which is what is needed for publishing a vscode extension) is covered by that. ↩

[cameron-martin]

Regarding your first point, it's possible it has already been removed but just requires pushing a commit to this branch after it was moved. I was told the CLA would no longer be necessary after the move.

[cameron-martin]

It appears the build job on CI isn't getting triggered now. Unsure if it's a flake or something else.

[adam-azarchs]

Actions aren't triggered by pushes made with GITHUB_TOKEN. There are three ways around that:

1. Use a token other than GITHUB_TOKEN. Generally undesirable because it requires managing a secret, with a token that has write access to the repo, so you really need to rotate it frequently.
2. Use a github app to provide the token. I think that's what was happening when it was part of the bazelbuild org, but it's hard for a non-admin to see if that's the case.
3. Enable workflow_dispatch for the required CI action and explicitly triggering it from the action which pushes the branch.

[cameron-martin]

@adam-azarchs How do you configure option 2? I can't find any docs on GitHub about this.

[github-actions]

🤖 Release is at https://github.com/bazel-contrib/vscode-bazel/releases/tag/v0.11.0 🌻

[adam-azarchs]

@adam-azarchs How do you configure option 2? I can't find any docs on GitHub about this.

I believe https://github.com/apps/release-please is what you'd be looking for there. To say the documentation for it is a bit thin would be an understatement.

[cameron-martin]

I see. I've requested installation for this repo so I guess we can see what happens once that goes through. For now I can push to this branch to trigger the CI, and I have just done a release using that method.

[adam-azarchs]

You can also just close the PR and reopen it, if you don't want your authorship in the commit history.

Of course there's still another step to the release process, as I mentioned above, which is to publish the release to the vscode marketplace, which is something that would ideally in the name of supply chain traceability be done by some GitHub actions automation.