| commit | a27b69c663f39f05583228844a4d39d418f0e2b5 | [log] [tgz] |
|---|---|---|
| author | Andrew Lamb <andrewlamb@chromium.org> | Tue Mar 17 15:42:25 2020 |
| committer | Commit Bot <commit-bot@chromium.org> | Wed Mar 18 09:30:54 2020 |
| tree | 8e415b439c1a9ff68884874b369232ea8572249a | |
| parent | ec47c411d3930af47967babc32eab648e3d1e76d [diff] |
Rename enums to be different from surrounding message. - Context: b/150293999 requires Java bindings for these protos. If a message and enum in the same file have the same name, javac can't compile the bindings. Rename "FormFactor" and "Stylus" enums. - go/proto-guidelines#rename-field suggests this is ok b/c type names are not serialized in binary protos (and AFAICT they aren't serialized in textpb either). We don't rely on old serialized protos anyway right now (i.e. regen'ing the protos is ok). - Changed references to these enums in ConstraintSuites. BUG=b:150293999 TEST=python unittests TEST=regen configs in program and project repos, no change in generated protos. Change-Id: I3aa5e0060e9cf5b0ac860623d73cf664faec7cef Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/config/+/2107501 Auto-Submit: Andrew Lamb <andrewlamb@chromium.org> Commit-Queue: C Shapiro <shapiroc@chromium.org> Reviewed-by: C Shapiro <shapiroc@chromium.org> Reviewed-by: Sean McAllister <smcallis@google.com> Tested-by: C Shapiro <shapiroc@chromium.org>
Before beginning verify that you have appropriate permissions to work with the project. This will usually mean having membership in the partner domain account that is configured for your project. Inquire with your local representative or Google contact if you need more information about the partner domain accounts configured for your project.
Follow the Chromium OS Quick Start Guide through to the end of the “Get the Source” section. This guide walks you through installing prerequisites and syncing the public Chromium OS source code into a $SOURCE_REPO directory. This step pulls down a lot of code and could take up to an hour.
Verify the name of your $PROGRAM and $PROJECT with your local representative or Google contact. These values will be used in the command below.
Run the following command to sync your $PROGRAM and $PROJECT from within your chromiumos checkout in the $SOURCE_REPO/src/config directory:
./setup_project.sh $PROGRAM $PROJECT
This command will execute a number of steps including checking out your program and project and other related repositories, symlinking a local manifest, and finally doing a full chromiumos sync.
The $SOURCE_REPO/src/config/bin directory contains utilties for working with your project. Add the directory to the end of your PATH. You will probably want to add this configuration in your ~/.bashrc file or other appropriate location so you don't have to repeatedly set the PATH:
export PATH=$PATH:$SOURCE_REPO/src/config/bin
If you got to this point without an error you are set up to start working on your project.
After setting up your project you'll want to note the location of several important repositories within the checkout:
Partners will rarely propose changes to src/config and occasionally propose changes to src/program/$PROGRAM. The bulk of a partner's work will occur in in src/project/$PROGRAM/$PROJECT.
Configuration changes are made to a project by adjusting the Starlark configuration definition in $SOURCE_REPO/src/project/$PROGRAM/$PROJECT/config.star and then running the gen_config script (added to the PATH above). An example session updating project configuration follows:
cd $SOURCE_REPO/src/project/$PROGRAM/$PROJECT/ $EDITOR config.star # Adjust contents of config.star and save. gen_config config.star
This will cause the generation of configuration payloads that can be found at:
These files represent the same configuration, one is in binary format and is used in production. The binary format is more flexible and allows easier evolution of the schema. The second is in text format. The text format is intended to allow the user to easily eyeball the effects of changes.
To submit the changes the user first commits the files and then submits them to commit queue (CQ):
git add . git commit # Add commit message with BUG= and TEST= directives repo upload .
This will result in a reviewable CL in gerrit. The exact URL will for your CL will be output when the CL is uploaded. The CL will need to be approved and pass CQ. Details on working with CLs and the progression through review and CQ can be found in the Chromium OS Contributing Guide and more specifically in the Going through review section. CQ verifies that you have correctly generated your configuration payload and that you have not violated the program's constraints.