I've been using it to package the opentelemetry-c++ sdk for us, with single command:
bazel run make_otel_sdk
it compiles debug, fastdebug, release, then it places the .dll, include/ folders, etc. into single zip. I'm also invoking sentry-cli to obtain all source code used and also place them in
At work in a top level .bazelrc I have caching on the intranet, but on the github I'm relying (not ideal) on the actions/cache through disk_cache blobs - it works, but storing back all "blobs" makes it a bit worse than expected.
Neat setup. I would point out that this shows some of the problems with the way bazel is managed as a project. You had to fix your build for bazel 8, which isn't great. But the bigger issue is you were forced to adopt rules_cc, which because of their weird adherence to "semantic versioning" means you are now subject to unannounced breaking changes, because rules_cc hasn't hit 1.0.
Rules_pkg went through the same problem: it was built in to bazel, then they moved it out into rules_pkg 0.0.1, then the maintainer of rules_pkg felt free to break everything multiple times, mostly for unjustifiable aesthetic reasons.
Yup! I'm using this project as playground to get better at Bazel, and also to evaluate for myself - "is this really a tool I can use at work" - "Not yet, because someone else must be mad as me to love it to use it, instead of use it to solve problems" - especially on Windows :)
bazel run make_otel_sdk
it compiles debug, fastdebug, release, then it places the .dll, include/ folders, etc. into single zip. I'm also invoking sentry-cli to obtain all source code used and also place them in
https://github.com/malkia/opentelemetry-cpp/actions/runs/120...
it produced this
https://github.com/malkia/opentelemetry-cpp/releases/tag/v1....
At work in a top level .bazelrc I have caching on the intranet, but on the github I'm relying (not ideal) on the actions/cache through disk_cache blobs - it works, but storing back all "blobs" makes it a bit worse than expected.