Repository navigation
build(release): build prebuilt tools in the release workflow - #4217
Conversation
rules_rust is only a dev dependency, so users can't build Rust tools like `exe_zip_maker` themselves; the tools must ship prebuilt. Before attaching them to releases, the release workflow should show that they build on each target platform. `//dev/release_artifacts:artifacts_for_release` builds its files with release settings through a transition: optimized, with glibc (Linux) or the C runtime (Windows) linked statically, and macOS 11 as the minimum. Presubmit's bzlmod `//...` builds now cover these settings too; under WORKSPACE, where rules_rust is a stub, the target is manual. The target also lists the files' paths, so scripts don't need `bazel cquery`. The release workflow now calls a reusable workflow that natively builds the target on Linux, macOS, and Windows (x86_64 and aarch64), with `--stamp` and the release tag as `--embed_label`, checks the Linux and macOS binaries' OS requirements, and uploads the binaries as workflow artifacts. Nothing is attached to the release yet, so a failed `bazel build` only adds a warning to the run. The workflow can also be run manually to try it before a release.
|
Ready for review. I'm not familiar with building rust stuff. The special flags to statically link glibc I find a bit strange, but 🤷 . I'd also prefer to cross build, but not sure what platforms we can cross-build do with rust. Google's rules_ml_toolchain has crossbuild for linux->{windows,mac} for c++, so i suspect its possible with rust, too, somehow. The AI seemed to prefer host-based builds, though, which I'm OK with doing, at least to get started. |
aignas
left a comment
aignas
left a comment
There was a problem hiding this comment.
LGTM as a first step, my comments are for future direction and can be addressed in separate code changes.
| runner: windows-11-arm | ||
| - triple: aarch64-unknown-linux-gnu | ||
| runner: ubuntu-24.04-arm | ||
| - triple: x86_64-apple-darwin |
There was a problem hiding this comment.
Ideally I would love the cross compiling happen from one host, that may facilitate supporting more esoteric platforms, as those will likely come from PRs adding cross compiling.
Make it explicit in build.sh that release artifacts are optimized. The release transition already sets opt for the files, so the binaries don't change; the flag makes the rest of the build match.
2 participants
This makes the release workflow build the exe zip maker tool as
part of releases. Because more plumbing is needed to integrate
prebuilt binaries, they are just built, but not actually
included into the final release. For that same reason, failures
to build are ignored for now.
This provides some basic verification of the overall flow and will
give an idea of how expensive it is to build them.
The binaries are built to be fully statically linked to minimize
system dependencies.
Work towards #4216