Allow customization of patch validation.
Allows authors to control patch validation strictness through the patch transformation definition. Generalizes the idea of the –patch-validate-on-load parameter to Starlark, and makes –patch-validate-on-load a CLI override mechanism with no default anymore. Effective default validation behavior is unchanged to before.
patch.quilt_apply also exits early if no series or patches could be found and validation is bypassed, ensuring no superfluous quilt setup is done in this case. refactored the code a bit to achieve this in a readable way.
Also cleaned up code a bit: used multiline string literals where appropriate, used newlines consistently for unit test structure.
BUG: 475203147 GWSQ_IGNORES: mschlaffer@google.com PiperOrigin-RevId: 917910800 Change-Id: Id32281e12399613f6c859ef4862fd70ed279893b
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
Copybara
A tool for transforming and moving code between repositories.
Copybara is a tool used internally at Google. It transforms and moves code between repositories.
Often, source code needs to exist in multiple repositories, and Copybara allows you to transform and move source code between these repositories. A common case is a project that involves maintaining a confidential repository and a public repository in sync.
Copybara requires you to choose one of the repositories to be the authoritative repository, so that there is always one source of truth. However, the tool allows contributions to any repository, and any repository can be used to cut a release.
The most common use case involves repetitive movement of code from one repository to another. Copybara can also be used for moving code once to a new repository.
Examples uses of Copybara include:
Importing sections of code from a confidential repository to a public repository.
Importing code from a public repository to a confidential repository.
Importing a change from a non-authoritative repository into the authoritative repository. When a change is made in the non-authoritative repository (for example, a contributor in the public repository), Copybara transforms and moves that change into the appropriate place in the authoritative repository. Any merge conflicts are dealt with in the same way as an out-of-date change within the authoritative repository.
One of the main features of Copybara is that it is stateless, or more specifically, that it stores the state in the destination repository (As a label in the commit message). This allows several users (or a service) to use Copybara for the same config/repositories and get the same result.
Currently, the only supported type of repository is Git. Copybara is also able to read from Mercurial repositories, but the feature is still experimental. The extensible architecture allows adding bespoke origins and destinations for almost any use case. Official support for other repositories types will be added in the future.
Example
Run:
Getting Started using Copybara
The easiest way to start is with weekly “snapshot” releases, that include pre-built a binary. Note that these are released automatically without any manual testing, version compatibility or correctness guarantees.
Choose a release from https://github.com/google/copybara/releases.
Building from Source
To use an unreleased version of copybara, so you need to compile from HEAD. In order to do that, you need to do the following:
git clone https://github.com/google/copybara.gitbazel build //java/com/google/copybarabazel build //java/com/google/copybara:copybara_deploy.jarto create an executable uberjar.bazel test //...if you want to ensure you are not using a broken version. Note that certain tests require the underlying tool to be installed(e.g. Mercurial, Quilt, etc.). It is fine to skip those tests if your Pull Request is unrelated to those modules (And our CI will run all the tests anyway).System packages
These packages can be installed using the appropriate package manager for your system.
Arch Linux
aur/copybara-gitUsing Intellij with Bazel plugin
If you use Intellij and the Bazel plugin, use this project configuration:
Note: configuration files can be stored in any place, even in a local folder. We recommend using a VCS (like git) to store them; treat them as source code.
Using pre-built Copybara in Bazel
If using a weekly snapshot release, install Copybara as follows:
.bazelrcfile:run --java_runtime_version=remotejdk_21http_jarto download the release artifact.load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_jar")http_jar = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_jar")[version]placeholder:/tools/BUILD.bazel) declare thejava_binary:bazel run, for examplebazel run //tools:copybara -- migrate copy.bara.skyBuilding Copybara from Source as an external Bazel repository
There are convenience macros defined for all of Copybara’s dependencies. Add the following code to your
WORKSPACEfile, replacing{{ sha256sum }}and{{ commit }}as necessary.You can then build and run the Copybara tool from within your workspace:
Using Docker to build and run Copybara
NOTE: Docker use is currently experimental, and we encourage feedback or contributions.
You can build copybara using Docker like so
Once this has finished building, you can run the image like so from the root of the code you are trying to use Copybara on:
Environment variables
In addition to passing cmd args to the container, you can also set the following environment variables as an alternative:
COPYBARA_SUBCOMMAND=migratemigrateCOPYBARA_CONFIG=copy.bara.skycopy.bara.skyCOPYBARA_WORKFLOW=defaultdefaultCOPYBARA_SOURCEREF=''COPYBARA_OPTIONS=''Git Config and Credentials
There are a number of ways by which to share your git config and ssh credentials with the Docker container, an example is below:
Documentation
We are still working on the documentation. Here are some resources:
Contact us
If you have any questions about how Copybara works, please contact us at our mailing list.
Optional tips
If you want to see the test errors in Bazel, instead of having to
catthe logs, add this line to your~/.bazelrc: