-
Notifications
You must be signed in to change notification settings - Fork 297
Description
I'm trying to use Copybara to release some subdirectories of my go monorepo as open source modules. I've got the bones of a solution but I don't love it and I'm very curious if there's a pattern I'm missing I could be using.
First off, I'm using go.mod "replace" directives to load my modules from source when operating inside the monorepo. This gives me the monorepo behavior I want of being able to have changes in any part of the monorepo immediately used by go build
But I'd like my published OSS repos to build correctly on their own, so they can't be using "replace" directives. That's an easy core.replace substitution with a regex. I can delete those replace directives as part of publishing.
However, the way that go's module system works, when I add an import that is replaced to my module, it makes an entry in the go.mod file to represent that it is on the local file system, like "github.com/macrael/exbar v0.0.0-00010101000000-000000000000". When I remove the replace directive and pull down the latest version of exbar in to my release OSS repo, it replaces it with the latest released tag, like "github.com/confidentsecurity/exbar v0.0.3".
this means that I can have a valid go.mod file if I use a transformation to replace the bogus version number with the latest tag of exbar as part of the copybara export. And that all works nicely b/c I can also specify that tag as the tag to deploy the dependent open source repos with using copybara as well.
git.destination.tag_name is a temptable string, so I can pass the right tag name into all those repos using a CLI label. This feels right, I can't have setting the tag number in code be part of our PR process, it will be out of sync as soon as PRs land in a different order in the merge queue. The copybara release process is the only thing that knows what version to tag our releases at. BUT I cannot access that label inside of core.replace.after, so I can't do the replace transformation, so my go.mod files will not be correct in our released code.
I could use a go template string to write a new copy of copy.bara.sky before invoking it, but that doesn't seem like the correct way to use copybara. Is there a way for me to specify the next tag I want to set and make it available as a variable in the copybara config instead of just as a temptable label? So that it can be input to git.destination.tag_name and to core.replace.after?
Thanks for your help! I saw another comment talking about other ways besides labels for data to get into the config but I don't know what the status of that effort is.
(additionally, I'm not entirely happy with even this proposed fix because my go.sum files will be out of date, so if there are other tricks for releasing go code from a monorepo as stand alone repos please let me know about it)