Skip to content

Latest commit

 

History

History
95 lines (82 loc) · 4.61 KB

RELEASING.md

File metadata and controls

95 lines (82 loc) · 4.61 KB

Releasing linux.bzl

Each rules release pins both its supported Linux source catalog and the platform-specific Kconfig graph generator archives. The generator has its own version and release assets; changing it is an explicit compatibility update to the rules module.

Prepare

  1. Choose a pre-1 semantic version and update the module version and release notes.
  2. Run bazel test //..., the standalone examples, and the Linux 6.12 and 6.18 compatibility builds for x86_64 and aarch64.
  3. Boot all four maintained kernel/architecture pairs under hermetic QEMU and verify that each reaches the initramfs userspace marker. For module-enabled configurations, also verify that the selected in-tree .ko loads.
  4. Build a named overlay and verify its kernel release and fixed output contract.
  5. Test a consumer that uses the canonical @linux.bzl repository, declares configured images through linux_images from extensions.bzl, and imports each facade repository explicitly with use_repo.
  6. On a Linux x86_64 executor with the registered stable Rust 1.97.0 toolchain, run bazel test //:linux_6_12_96_rust_module_test //:linux_6_18_39_rust_module_test --test_output=streamed from e2e. This builds and loads version-native Rust-for-Linux modules for the cataloged x86_64 kernels. Also verify that cross-kernel dependencies and Rust MODULE_VERSION/module source-version metadata are rejected. Build the C source-version fixture to verify MODULE_VERSION and CONFIG_MODULE_SRCVERSION_ALL through modpost.
  7. From aya_e2e, run the pinned Aya x86_64 and aarch64 VM targets in one Bazel invocation. This exercises the shared action graph and records cross-target action deduplication in one profile and BEP.
  8. Audit the pinned source URLs and integrities in the catalog.
  9. Audit KCONFIG_TOOL_VERSION and all six entries in internal/kconfig_tool_releases.bzl.

When updating the generator, first publish deterministic kconfig-<version> archives for Linux, macOS, and Windows on amd64 and arm64. Each archive must contain kconfig_parse at its root. Compute the Subresource Integrity values from the published assets, update the checked-in table, and run repository-generation smoke tests for every host archive. Rebuild the archives once from a clean checkout and compare digests.

After verifying the generator commit, create and push its release tag with:

VERSION=vX.Y.Z ./release_kconfig.sh

Publish

  1. Tag the verified release commit as vX.Y.Z and push the tag. The release workflow creates the module source archive and starts the BCR publishing workflow using the configuration under .bcr/.
  2. Verify the release archive and the generated BCR pull request.
  3. Test a clean consumer module using the tag, without local_path_override or a locally built generator.

Support checks

A release is ready only when:

  • Bazel 8.x and 9.x pass the root test suite.
  • Linux 6.12 and 6.18 build for x86_64 and aarch64 with the registered Bazel C++ toolchains.
  • All four maintained kernel/architecture pairs boot under the registered QEMU system toolchains, reach the initramfs userspace marker, and exercise configured module loading.
  • The fixed :modules, :module_symvers, :modules_order, :modules_builtin, and :modules_builtin_modinfo labels produce the corresponding Kbuild artifacts.
  • Rust-for-Linux modules build for the cataloged x86_64 Linux targets on a Linux x86_64 executor with stable Rust 1.97.0 through the public linux_module API. Cross-kernel module dependencies and Rust MODULE_VERSION/module source-version metadata fail explicitly.
  • C modules support MODULE_VERSION; in-tree C/assembly modules and out-of-tree C modules support CONFIG_MODULE_SRCVERSION_ALL, while direct authored srcversion= metadata fails explicitly.
  • The pinned Aya x86_64 and aarch64 VM tests pass from the standalone aya_e2e module root.
  • BPF-syscall and BTF-enabled configurations are covered by a compatibility build.
  • Repository generation is smoke-tested with all six host generator archives.
  • The base and named-overlay repositories produce the documented fixed outputs.
  • Unsupported Kbuild constructs and toolchain/config mismatches fail with actionable diagnostics.

Named variants must share content-identical object actions in one configured graph. Release CI verifies the maintained x86_64 base/BTF/debug/LZ4 invocation against the generated graph statistics and Bazel action metrics.

Signing kernel images or modules, Rust module source versions, direct authored srcversion= metadata, and device-tree artifacts are outside the current release contract.