Provide BCR publish workflow

[mmorel-35]

Description

This Provides the publish-to-bcr workflow to publish the Bazel MODULE to the Bazel Central Registry after release.

This requires #114 to be merged first

[wu-sheng]

Who owns this release TOKEN?
We didn't have that release pipeline for BCR before.

[mmorel-35]

Yes before bzlmod there was no BCR, I believe the token needs to be provided by the owners of skywalking-data-collect-protocol. It's explained at create a PAT in https://github.com/bazel-contrib/publish-to-bcr

[wu-sheng]

In the ASF, release requires the source tar and the vote process. We can't do this directly.
The tag in this repo is from the main repo voting. But as the main repo(skywalking backend) is written in Java, we don't release this in any other platform, just binary tar.
All agents are built based on the proper commit ID according to their own implementation.
The collection protocol is kept compatibility as much as possible for years.

I think we don't have enough motivation to maintain the new release, as it is going to require the release process changes.

[mmorel-35]

@wbpcode,

As cpp2sky is using skywalking-data-collect-protocol and would benefit from it being published in the BCR, what do you think?

[mmorel-35]

The proposal to publish to Bazel Central Registry (BCR) does not require changes to the established ASF release process. The workflow operates after a release is tagged and the source tarball is produced according to ASF policy. Bazel Central Registry stores metadata that references the externally hosted source tarball (for example, the GitHub release asset), and does not duplicate or host the tarball itself. The only additional requirement is the use of a GitHub Personal Access Token, configured once by repository maintainers, to enable automated publication to BCR.

Minimal ongoing maintenance is expected. Once the workflow is set up, each tagged release is automatically registered in BCR. For each new version, an approval is required in the BCR repository, ensuring compliance and quality for the registry. No fundamental changes to agent builds or compatibility policies are necessary.

The primary benefit is improved dependency management for downstream projects such as cpp2sky and others. By registering with BCR, these projects can retrieve skywalking-data-collect-protocol directly from the registry, avoiding repetitive use of git_override in Bazel MODULE files and streamlining integration across the ecosystem.

This addition enhances visibility and usability for the protocol with negligible impact on release or maintenance procedures.

[wu-sheng]

The query protocol has nothing related to cpp codes.