commit | 82fd7653c428175636e24d112611513a69db45fb | [log] [tgz] |
---|---|---|
author | chromeos-ci-prod <chromeos-ci-prod@chromeos-bot.iam.gserviceaccount.com> | Thu Jul 25 20:38:10 2024 |
committer | chromeos-ci-prod <chromeos-ci-prod@chromeos-bot.iam.gserviceaccount.com> | Thu Jul 25 20:38:10 2024 |
tree | d151c9f3edcacbe444b0ba5eb773173ebbbb52e0 | |
parent | 386496670096a45c8b37231750ef5c4942ce1db8 [diff] |
Syncing with internal manifest Cr-Build-Url: https://cr-buildbucket.appspot.com/build/8741409382538224401 Cr-Automation-Id: cros_source/push_uprevs Change-Id: I010db25f36edc74271d6ed971019e08627795175
The Repo tool manages our local checkouts. See our CrOS Source Layout documentation for much more detailed information.
See the upstream repo manifest format documentation for general info on manifests and its specification.
Some files are automatically synced between the internal manifest project and the public manifest project. Changes to these files must not be made in the public manifest project as they will be automatically clobbered. It also means that care must be taken to only include public information in these files to avoid accidental leaks.
If you're not a Googler and want to update one of these files, then please file a bug instead for assistance.
If you want to update the list of synced files, see the cros_source recipe.
The current list of files:
codesearch-chromiumos.xml
DIR_METADATA
full.xml
README.md
_kernel_upstream.xml
_remotes.xml
Official builders sync using the official.xml
manifest which may include more projects than most developers need or want.
The CQ does not automatically watch new or all projects. The list of projects with CQ coverage is manually maintained in ~/chromiumos/infra/config/
in the chromeos_repos.star
file.
Whenever a new project is added to the manifest, the developer adding it is also responsible for updating the CQ config.
This is an unfortunate KI with the CQ and is tracked in http://b/206800931.
See the How do I test a manifest change? FAQ for more detailed information.
The CQ should provide decent coverage too.
Here is a quick hack method:
~/chromiumos/.repo/manifests/
repo sync --no-manifest-update
to use the local manifest files on disk~/chromiumos/.repo/manifests/
One can check out a subset of the manifest using the repo groups
feature. This section documents the important groups that we use.
This group is the minimum subset of repos needed to do a full build of Chrome OS. It doesn't include all of the repos to necessarily test the OS image but does include all those needed to create an image.
The subset of repos needed to perform release actions i.e. payload generation, etc. Used by release engineers, TPMs, and Infra team members. Note this group isn't useful without a checkout of manifest-internal.
Tools needed to perform routine lab administrative actions like DUT re-allocation or lab server management.
List of specific annotations we use:
<project>
branch-mode
: tot
, pin
, drop
, create
(default). How the project should be handled when creating a new branch.tot
: track the same upstream/revision as the source branch.pin
: pin the project to whatever commit it is at in the source branch.drop
: drop the project from the manifest in the newly created branch.create
(default): create a new branch for the project.branch-suffix
and no-branch-suffix
. Used to override default branching behavior for projects with multiple checkouts. no-branch-suffix
will drop any sort of suffix. branch-suffix
provides a custom suffix to be used for that checkout (note that branch_util
already prefixes the suffix with a -
, so you shouldn't include one in the annotation).<remote>
public
: true
, false
(default). Whether the remote is publicly accessible (i.e. external). Currently used by the Manifest Doctor to determine which projects to include in external buildspecs (see go/cros-public-buildspecs).