bazel-contrib / rules-template Goto Github PK
View Code? Open in Web Editor NEWA template for creating a new Bazel ruleset
License: Apache License 2.0
A template for creating a new Bazel ruleset
License: Apache License 2.0
Many languages require building and using supplementary tools, like @io_bazel_rules_go's use of a builder tool. Is there guidance on the "right" way to author tools which are used by this rules-template, and hook them up to the ruleset? What about if mylang is not an appropriate language in which to author these tools?
In the past, I've written these tools as:
I experienced some problem as I released a project that is based on rules-template
.
v0.0.0
- ❌ failed.permissions
key in the workflow as described in this commentv0.0.1
- ✔️ succeededv0.0.2
- ✔️ succeededIt seems setting the permissions in the settings or in the workflow file, respectively, fixes the issue.
Did anybody else had this problem? Is this worth a note in the README.md
?
I'm thankful for any feedback 🤘
I recently observe in https://github.com/aherrmann/rules_zig/ that the toolchain is managed via a rule called zig_repository
, which follow the template convention of mylang_repository
.
However, what I am used to in Go is go_repository
is used to manage 3rd party dependency import. Toolchain in Go is managed via go_{download,local,host}_sdk
and go_register_toolchains
rules instead.
So I would suggest renaming mylang_repository
to mylang_sdk
and mylang_register_toolchains
while reserving mylang_repository
for respective language's 3rd party import. WDYT?
In bazelbuild/rules_pkg#716 (comment) there's a suggestion that rules need complexity in their release process in order to make them secure.
I believe we have already followed excellent security practices in the way releases are created here. By only allowing a developer with write access to push a tag, there's no way to create a release with contents that aren't reproducible from the sources.
I'd be very interested to know of any vulnerabilities with our approach, as there are now dozens of rulesets based on this template.
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
mylang/repositories.bzl
bazel_skylib 1.7.1
MODULE.bazel
e2e/smoke/MODULE.bazel
bazel_skylib 1.7.1
.bazelversion
bazel 7.2.1
.devcontainer/Dockerfile
.github/workflows/buildifier.yaml
actions/checkout v4
.github/workflows/ci.yaml
bazel-contrib/.github v6
technote-space/workflow-conclusion-action v3.0.3@45ce8e0eb155657ab8ccf346ade734257fd196a5
.github/workflows/release.yml
bazel-contrib/.github v6
The template defined in this repository and the corresponding GitHub actions configuration configure a --repository_cache
to be cached with the GitHub actions cache. However, in my experience, fetching artifacts from the GitHub actions cache is often slower than fetching the artifacts directly from the internet in a GitHub actions run.
I've set up a simple example to illustrate this: In that case we use Bazel to download binaries of varying sizes and either use Bazel's repository cache feature to cache on GitHub actions cache or not. In the case of a download artifact of about 200MiB in size the full build step (including the download of Bazel itself) takes about 9s. However, with the GitHub actions cache enabled the download of the cache alone takes 1m6s. According to the cache action's outputs the download itself is fast at somewhere around 130MB/s, but the overall step duration brings this down to about 3MB/s. (Perhaps the decompression takes so long.)
On smaller sized artifacts the difference vanishes, the GitHub actions run takes about the same time whether the repository cache is used or not. So, in such cases the repository cache doesn't add much value, but only drives up the storage used.
This begs the question, should we recommend a repository cache in the rules template, or is it better to remove it from the example CI configuration?
(Relevant changes d017a1d and aherrmann/.github@07b6368)
See https://copier.readthedocs.io/en/stable/
This will allow to do the:
steps for the automatically user after asking for those details.
Also, when this template involves, users can use Copier to pull in those changes to their instantiated projects. Ref: https://copier.readthedocs.io/en/stable/updating/
With the upcoming release of 6.0.0 would it make sense to set the default implementation for new rule sets to use bzlmod by default?
Could we at least consider showing some side by side examples in the same style shown here? https://github.com/bazelbuild/examples/tree/main/bzlmod/04-local_config_and_register_toolchains
The mylang_register_toolchains
macro invokes toolchains_repo
which generates a toolchain
target for each platform as well as a resolved_toolchains
target that acts as an alias for the currently resolved toolchain. This is intended as a workaround for bazelbuild/bazel#14009 to expose make variables to rules that want to directly depend on the "mylang" toolchain, e.g. genrule
.
Because the resolved_toolchains
target is generated as part of toolchains_repo
users have to know and use the name given to that external workspace. E.g. in the example setup a user would have to use the label @mylang1_14_toolchains//:resolved_toolchain
. This is problematic:
mylang_register_toolchains
or toolchains_repo
at all, then there will be no resolved_toolchains
target.There is no reason why resolved_toolchains
has to part of or linked to toolchains_repo
or mylang_register_toolchain
. I propose that resolved_toolchains
should be defined in com_myorg_rules_mylang
directly, instead.
Note: fix for this already exists in #35 , just providing additional context.
After forking this, I noticed that the cache actions were failing to persist with the following error
Warning: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.
Which was surprising because these paths do, in fact, exist! After reading the yaml docs on how the vertical bar operator works, my understanding is that
path: "~/.cache/bazel"
results in
~/.cache/bazel
in github's action processor, whereas
path: |
"~/.cache/bazel"
"~/.cache/bazel-repo"
results in
"~/.cache/bazel"
"~/.cache/bazel-repo"
because it doesn't unquote, and the processor isn't handling that at all. Switching to
path: |
~/.cache/bazel
~/.cache/bazel-repo
fixes the caching.
There seems to be an issue with the buildifier check on Windows CI.
The error is the following
ERROR: D:/a/rules-template/rules-template/.github/workflows/BUILD.bazel:3:11: While resolving toolchains for target //.github/workflows:buildifier.check: No matching toolchains found for types @buildifier_prebuilt~6.1.0//buildifier:toolchain.
The first occurrence seems to have been here
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.