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:
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
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:
repo sync --no-manifest-updateto use the local manifest files on disk
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:
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.
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).