Usage question

[emanuelez]

I'm evaluating Copybara but the lack of documentation makes it a bit hard to understand some basic concepts.

Let's suppose there a private repo A and a public repo B, both hosted on Github. B is a filtered version of A, in the sense that some files and folders are removed. Most work (internal) will happen on A, but some public contributions might happen on B as pull requests. My understanding so far is that I would have to setup webhooks on both repos. On A to mirror branches to B on commits, and on B to mirror PRs to A.

Is my understanding correct?

thank you for the product and your attention!

[mikelalcon]

Hi Emanuele, At the high level yes. That would be the workflow. Here are some specifics: You'll need two workflows: 1) An ITERATIVE workflow* from private to public*. origin_files glob should match the files mean to be public. You can use destination_files to exclude files in destination if there are files that are only present in the destination. You probably want to use authoring = pass_thru/whitelisted. You might as well use metadata.map_author if you want to map internal users to external ones (like Foo <foo@corp.com> -> Foo <bar@gmail.com>) . You want to also add metadata.restore_author for authors coming from workflow 2). You might want to add metadata.verify_match for checking every file has licenses and metadata.verify_match(verify_no_match = True) to check that some confidential string is not present. You can also use metadata.scrubber to remove confidential information from commit messages. 2) A CHANGE_REQUEST workflow *from public to private. *This workflow is used to migrate PR to the private repo. CHANGE_REQUEST is the workflow used to import changes from non-source of true repos (That could be behind) to the SoT. Once you do an export with 1) and PR are created with baselines with 1) it should detect the baseline automatically when importing. You might want to add metadata.save_author so that the author name is saved as a label (ORIGINAL_AUTHOR). This allows the internal user doing the import to add additional changes to the internal part of the code to make it compile internally (imagine that the change in the PR is incompatible with the internal code). Cheers, Mikel.

…

On Fri, Aug 25, 2017 at 8:04 AM Emanuele Zattin ***@***.***> wrote: I'm evaluating Copybara but the lack of documentation makes it a bit hard to understand some basic concepts. Let's suppose there a private repo A and a public repo B, both hosted on Github. B is a filtered version of A, in the sense that some files and folders are removed. Most work (internal) will happen on A, but some public contributions might happen on B as pull requests. My understanding so far is that I would have to setup webhooks on both repos. On A to mirror branches to B on commits, and on B to mirror PRs to A. Is my understanding correct? thank you for the product and your attention! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6bQFBWpsRNJR2FHq23h_LlxhMHfdvsks5sbrhpgaJpZM4PCk5B> .

[emanuelez]

Thank you very much! That's precious info!

One more question: can I use wildcards or any other mechanism to work on several branch names and PR numbers?

[mikelalcon]

No, but you can pass it as a parameter to the tool. For example (Assuming git.github_origin):

copybara copy.bara.sky workflow_name #22

or

copybara copy.bara.sky workflow_name my_branch
copybara copy.bara.sky workflow_name v1.0.1_tag

(Assuming the PR is still open).

We've been thinking on adding a wrapper that does it for all open PRs, but it is tricky if you have lot of open ones (We could limit by caching updated_at, but it involves some refactors).

[emanuelez]

That sounds great! But then I see a problem with moving PRs... the default push location for the destination is master, and I cannot hard-code the destination reference since I want it to be a PR as well, with an unknown PR number. Any way around this?

[mikelalcon]

Indeed :)

For PR we have just added a github_pr_destination:

https://github.com/google/copybara/blob/master/java/com/google/copybara/git/GitModule.java#L270

The documentation is still not shown in the public docs but should be usable (Internal customers are using it).

git.github_pr_destination(url = 'https://github.com/google/copybara')

For now you'll need to pass --github-destination-pr-branch branch_name. But soon we will expose a feature to expose the PR number from the origin to the destination.

For regular branches/tags/etc. You can use regular git.destination and the flag --git-destination-push