How to efficiently develop with multiple unmerged dependent modules from the same repo.

[kittiu]

@yajo thank you for the Doodba, it is awesome. We are trying to adopt it for our development workflow.

I admitted that I was first confused how to use Doodba for development especially with OCA. But I think I read somewhere that Dooda is build for "PR" first, and the merged PR will auto land into production. This message clear things up for me.

I have no problem working with a single module (or PR) or a module that depends on unmerged modules from other repos (config repos.xml for those modules).
https://github.com/Tecnativa/doodba-copier-template/blob/stable/docs/faq.md#how-do-i-develop-for-an-external-repo-such-as-oca

But given for example, I have module A, B, C, D (PRs) depending on one another, from the same repo. I want to fix some things in D which on module A, B, C. What should I do to prepare for deveopment?

Is this correct?

1. Checkout branch A, B, C from its PRs one by one and put each module in into private folder manually
2. Use addons.xml to get the repo folder, and checkout branch D to work with it?

But says, I then found something to fix first in module C, which of course depends on some other module in the same repo. Do I have to the same steps to prepare things for module C? Is this correct?

Thanks!

[pedrobaeza]

Well, here the problem is not strictly of Doodba, but git in general.

For having all the needed code in you development environment, Doodba can help you through repos.yaml file, allowing you to define the remotes (OCA and yours) and to auto-merge all the PRs or branches (A, B, C and D) automatically. I suppose you know the syntax that is specified in the file or help.

Launching the command invoke git-aggregate will download needed source code and leave you in your environment the result of merging all together. You end up then with a branch that combines everything together. On it, you can debug, test, etc and perform the needed changes for doing it to work. One possible technique from this is:

• Stash the changes locally (git stash).
• Fetch the target remote and branch (fetch <remote> <branch>).
• Change to that branch (git checkout <branch> or git checkout -b <branch> <remote>:<branch>).
• Recover stashed changes (git stash pop).
• Commit them and push.

This gets more complicated if the changes belongs to several branches, but I think you get the basic idea.

[kittiu]

Got it! Thank you @pedrobaeza , this is helpful.

[joao-p-marques]

Hi @kittiu

Maybe @yajo can give a help here, but I think your use case would end up being something like this:

From what I understood, you wanted to fix some things in module D, which depends on modules A, B and C, correct? In this case, what Doodba does (using git-aggregator) is to gather all the code declared in repos.yaml and addons.yaml. So, if you need to gather from different PRs in the same repo, you just add them to the appropriate section in repos.yaml. Something like:

# ...
some-repo:
  defaults:
    depth: $DEPTH_MERGE
  remotes:
    oca: git@github.com:OCA/some-repo.git
  target: oca $ODOO_VERSION
  merges:
    - oca $ODOO_VERSION
    - oca refs/pull/123/head # PR for module A
    - oca refs/pull/124/head # PR for module B
    - oca refs/pull/125/head # PR for module C
    - oca refs/pull/126/head # PR for module D
    - oca refs/pull/127/head # Another PR for module D

You don't need to check anything into the private folder, because git-aggregator does that for you. You can find out more about it in the project page: https://github.com/acsone/git-aggregator

[kittiu]

@joao-p-marques thank you. My understand is when we merge many things into a branch, this branch is good for debugging and testing, but not good for commit new code and push to a PR, am I right?

[joao-p-marques]

Well, yes, when you do it through the method explained above, git-aggregator will get the code for the default branch (corresponding to ODOO_VERSION) and then apply each PR in a merge commit, which would end up "dirtying" up your commit history with some things you probably won't want to push in you own PR.

So, for development, you could do what @pedrobaeza suggested, i.e., commit your changes in a separate branch independent to the ones pulled with git-aggregator.

[kittiu]

Besides, I have read what private folder is from the manual, and understand from technical PoV. I wonder what are good use case for private folder ?

[joao-p-marques]

The private folder is made to store the addons that are not Odoo core addons and that neither belong to any other repo (OCA or others).

[pedrobaeza]

@kittiu Doodba scaffolding is thought for having one per project (your customer using Odoo), so it will contain private addons that are only for that customer.

As reference, I have:

• Scaffolding for customer 1
• Scaffolding for customer 2
• Scaffolding for customer 3
• ...
• Scaffolding for migrating modules to v12
• Scaffolding for migrating modules to v13
• Scaffolding for migrating modules to v14
• ...

[kittiu]

Excellent !!!