3

My project is a monorepo where the top level directory contains build infrastructure and a set of project directories for different services. Each service has its own branch of development. The branches have rc and release tags: service1-14.0-rc1 for the first service and so on.

The issue is the build infrastructure that is shared between the products. I do not know if shared work should be done on the master branch and then merged into all the product branches, and the branches should be merged back into master occasionally, and at what cadence, etc. What is a good git methodology for this setup where the product branches will exist forever? Should tags be used for master at all?

Improve this question
3
  • 1
    Is there a reason you don't release from the main branch?
    – mmathis
    Commented Sep 2, 2022 at 18:01
  • I think the fundamental problem is that each service has it's own development branch. What happens when Service B needs a change done in the dev branch for Service A? What benefit does isolating changes to each service give you? Branches can be used to isolate work. They are also used to integrate work. There is value in both.
    – Greg Burghardt
    Commented Sep 2, 2022 at 18:18
  • I made a mistake by using the word service. Each "service" is a a completely separate platform with the same set of components being built for each platform. So service1 and service2 each need components a, b, c, and service 2 may additionally require d, e, but the platforms have no dependancies on each other. This project is primarily a build system, which is why it's a monorepo with shared build infra for all platforms. Each branch changes a few lines in a Makefile to build only one of the platforms and components against the platform.
    – linethepanic
    Commented Sep 2, 2022 at 23:09

2 Answers 2

Reset to default
2

In a comment you wrote

"Each branch changes a few lines in a Makefile"

I think there is your problem. Create one makefile which allows to build each product/platform individually, maybe by calling "make platform1", "make platform2" etc. Proceed the same way with other shared components - make sure they don't differ between platforms, but provide a compile time or runtime mechanics to adapt themselves to the specific platform where they are used for.

Now you can merge everything back into master without abusing branches for different products / platforms, which should make your issues vanish.

Improve this answer
6
  • The components are kernel modules and the platforms are different versions of the same kernel, so they have to be copied and adjusted for each kernel ABI. Running make kernel or make mod1 will build it against the dist/arch/kernel version that is set as makefile vars on each branch.
    – linethepanic
    Commented Sep 3, 2022 at 2:33
  • 2
    @linethepanic: my answer stands: find a way to switch between platforms outside of Git, so you don't have to abuse Git branches for what you are trying to accomplish.
    – Doc Brown
    Commented Sep 3, 2022 at 2:40
  • 2
    @linethepanic: I see this a lot with version control questions. Version control is meant to track changes to source code. Dependency management, platform management, deployment logic and information — all of these things are not problems version control was meant to solve.
    – Greg Burghardt
    Commented Sep 3, 2022 at 23:51
  • I agree with the approach here - depending on the complexity, you could consider treating makefiles as ephemeral artefacts - i.e. not storing the runnable makefiles in git but generating them as part of a pre-make script instead - for example, using a templating system such as mustache or ERB.
    – Ben Cottrell
    Commented Sep 4, 2022 at 6:23
  • @GregBurghardt we are tracking changes to modules against many different versions of the kernel that are maintained using the same repo. This is essentially the model kernel.org uses for their stable repo, but with two major differences: 1. We are maintaining the same kernel version for multiple distros/archs, so there is no clear version for master to track. 2. We need to have a methodology to take changes to the Make plumbing and merge it into all the kernel branches.
    – linethepanic
    Commented Sep 4, 2022 at 16:19
0

You can't just put everything in one git repo and call it a "monorepo"

If you don't have any cross over between the products sub directories then make them separate repos and save yourself this pain.

If you do have shared code then you need to be releasing from master and merging back. Which, if you are doing a monorepo probably means you need custom merging procedures to detect conflicts and reject based on whether you can build and deploy with no test failures.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.