| commit | 7ec7bbbfbdd839320cf2dd5fbcb89e3ba532f7d6 | [log] [tgz] |
|---|---|---|
| author | Raul E Rangel <rrangel@google.com> | Thu Apr 20 15:34:31 2023 -0600 |
| committer | Chromeos LUCI <chromeos-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Aug 08 00:23:46 2023 +0000 |
| tree | 2a36f1280ea7fc0185b3f11e0ffe6356fcb0d472 | |
| parent | 14bd3da9c985e96426e8ba555fdefe2949b25040 [diff] |
alchemist: Generate an @portage symlink in workspace root
It's kind of a pain right now to find the generated @portage repo.
Especially with the migration to bzlmod. The @portage repo doesn't exist
in any of the generated `bazel-` directories. This change
creates a @portage symlink in the workspace root. This makes it easier
for people to browse the generated repo. As a nice side effect, it also
fixes tab completion!
The alternative to this CL is to do the following:
$ ls bazel-out/../../../external/_main~portage~portage/
This will be difficult for people to discover and remember.
In order to prevent `bazel build //...` from unexpectedly building
this repository, I'm guarding it behind an environment flag. This way
people will be aware of this case.
BUG=b:264578578
TEST=BOARD=arm64-generic bazel query @portage//:all
TEST=BOARD=arm64-generic bazel query @portage//<tab><tab>
Change-Id: I3cd809e25d3dd527a6400a4785cb3e0a3ff8b37f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/bazel/+/4595138
Reviewed-by: Matt Stark <msta@google.com>
Commit-Queue: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Shuhei Takahashi <nya@chromium.org>
Tested-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Bain <tbain@google.com>
This repository provides the implementation to build ChromeOS with Bazel.
Building ChromeOS with Bazel is currently possible only on a special branch for Bazel development. Use the following repo command to check out the branch with a few additional repositories.
$ mkdir ~/chromiumos $ cd ~/chromiumos $ repo init -u https://chrome-internal.googlesource.com/chromeos/manifest-internal -b stabilize-15429.B -g default,bazel $ repo sync -c -j 4 $ cd src
Unless otherwise specified, examples in this doc assume that your current directory is ~/chromiumos/src.
Now you're ready to start building. To build a single Portage package, e.g. sys-apps/attr:
$ BOARD=amd64-generic bazel build @portage//sys-apps/attr
To build all packages included in the ChromeOS base image:
$ BOARD=amd64-generic bazel build @portage//virtual/target-os:package_set
which bazel prints a path under your depot_tools checkout. The wrapper script provided by depot_tools performs additional tasks besides running the real bazel executable.Inside CrOS SDK chroot (i.e. the build environment you enter with cros_sdk command), you should be able to run the same bazel build command.
You can also run build_packages --bazel --board=$BOARD to run build_packages with Bazel.
We have the following targets to build images:
//bazel/images:chromiumos_minimal_image: Minimal image that contains sys-apps/baselayout and sys-kernel/chromeos-kernel only.//bazel/images:chromiumos_base_image: Base image.//bazel/images:chromiumos_dev_image: Dev image.//bazel/images:chromiumos_test_image: Test image.As of June 2023, we primarily test our builds for amd64-generic and arm64-generic. Please file bugs if images don't build for these two boards. Other boards may or may not work (yet).
Building a ChromeOS image takes several hours. Most packages build in a few minutes, but there are several known heavy packages, such as chromeos-base/chromeos-chrome that takes 2-3 hours. You can inject prebuilt binary packages to bypass building those packages. See Injecting prebuilt binary packages for more details.
After building an image, you can use cros_vm command available in CrOS SDK to run a VM locally. Make sure to copy an image out from bazel-bin as it's not writable by default.
$ cp bazel-bin/bazel/images/chromiumos_base_image.bin /tmp/ $ chmod +w /tmp/chromiumos_base_image.bin $ chromite/bin/cros_vm --start --board=amd64-generic --image-path /tmp/chromiumos_base_image.bin
You can use VNC viewer to view the VM.
$ vncviewer localhost:5900
You can also use cros_vm command to stop the VM.
$ chromite/bin/cros_vm --stop
The run_tests.sh script runs currently available tests:
$ portage/tools/run_tests.sh
Optionally, you can skip running some tests by specifying some of the following environment variables when running run_tests.sh: SKIP_CARGO_TESTS=1, SKIP_BAZEL_TESTS=1, SKIP_PORTAGE_TESTS=1.
portage/ ... for building Portage packages (aka Alchemy)bin/ ... executablescommon/ ... common Rust/Go librariesbuild_defs/ ... build rule definitions in Starlarkrepo_defs/ ... additional repository definitionsprebuilts/ ... defines prebuilt binariessdk/ ... defines the base SDKtools/ ... misc small tools for developmentimages/ ... defines ChromeOS image targetsworkspace_root/ ... contains various files to be symlinked to the workspace root, including WORKSPACE.bazel and BUILD.bazelIf a package is failing to build, it‘s sometimes useful to view the package’s work directory. To do this run:
bazel build --sandbox_debug //your/ebuild
In the build output you will see a cd into the execroot:
cd /home/rrangel/.cache/bazel/_bazel_rrangel/ca19c0757f7accdebe9bbcbd2cb0838e/sandbox/linux-sandbox/842/execroot/__main__
This directory will contain a directory called build_package.*. It contains all the artifacts that were generated while building the package.
Build logs can be found in:
scratch/diff/build/arm64-generic/tmp/portage/logs/
The package work dir can be found in:
scratch/diff/build/<board>/tmp/portage/<category>/<package>-<version>
Sometimes you want to enter an ephemeral CrOS chroot where a package build is failing to inspect the environment interactively.
To enter an ephemeral CrOS chroot, run the following command:
$ BOARD=arm64-generic bazel run @portage//sys-apps/attr:debug -- --login=after
This command will give you an interactive shell after building a package. You can also specify other values to --login to choose the timing to enter an interactive console:
--login=before: before building the package--login=after: after building the package--login=after-fail: after failing to build the packageIn the case your work is blocked by some package build failures, you can workaround them by injecting prebuilt binary packages via command line flags.
For every ebuild target under @portage//internal/packages/..., an associated string flag target is defined. You can set a gs:// URL of a prebuilt binary package to inject it.
For example, to inject a prebuilt binary packages for chromeos-chrome, you can set this option:
--@portage//internal/packages/stage1/target/board/chromiumos/chromeos-base/chromeos-chrome:114.0.5715.0_rc-r2_prebuilt=gs://chromeos-prebuilt/board/amd64-generic/postsubmit-R114-15427.0.0-49533-8783437624917045025/packages/chromeos-base/chromeos-chrome-114.0.5715.0_rc-r2.tbz2
You can run generate_chrome_prebuilt_config.py to generate the prebuilt config for the current version of chromeos-chrome.
% BOARD=amd64-generic portage/tools/generate_chrome_prebuilt_config.py
We have several named config groupings in prebuilts.bazelrc that define typical options to inject prebuilts. You can specify --config to use them.
--config=prebuilts/arm64-generic: Injects prebuilt binary packages needed to build arm64-generic images.In case you need to extract the contents of a binary package so you can easily inspect it, you can use the xpak split CLI.
bazel run //bazel/portage/bin/xpak:xpak -- split --extract libffi-3.1-r8.tbz2 libusb-0-r2.tbz2
If you'd like to run the tests every time you commit, add the following. You can skip it with git commit --no-verify.
cd ~/chromiumos/src/bazel ln -s ../../../../../src/bazel/portage/tools/run_tests.sh .git/hooks/pre-commit