[Question] Am I shooting myself in the foot by considering using submodules rather than repos.yml?

[theangryangel]

Kinda wondering, am I shooting myself in the foot by using git submodules and leaving repos.yml blank?

To explain why I'm considering submodules rather than repos.yml;

• We already use submodules, so it's a workflow we know well
• Currently we do per-project modifications which aren't feasible as modules via patch files, but it looks like that's not supported right now in git-aggregator. So that's fine, and I know that's something I'll need to implement at some level if we continue it... I guess to ignore this point we could look at maintaining a fork of Odoo with these patches in branches to maintain them under git-aggregator and repos.yml instead?
• We pull from several private repos, over HTTPS (SSH isn't an option currently, as much as I would like it to be), often via paths relative to the project (i.e. ../group/somemodule/). Currently, unless I'm being dumb using repos.yml I can only get it to pull via full URLs and unless I'm being dumb, we have no way to share git-credential-cache from the host when running setup-devel.yaml stage, meaning we have to enter creds often on build
• It gives us the opportunity to leverage a single local copy of an upstream repo through references, etc. on dev machines

[yajo]

In general, I'd answer yes, you're :boot: :gun:

Submodules have some usability issues that don't come with git-aggregator. Also they don't allow you to merge code downstream, which is something really useful according to our experience.

You have an ssh folder in the scaffolding, which lets you drop in a private/public key pair to be able to clone via ssh. Alternatively you can download from https specifying a remote like https://user:password@host/repo.git.

Of course, both methods imply that anybody having access to your doodba repo has access to the repos it uses, but that's a sane assumption because:

1. Not having that code but having access to the scaffolding is like not having access to the scaffolding because you cannot reproduce the environment and then the whole point of this is lost.
2. You can use deployment tokens or keys for those accesses, so if somebody loses access to the scaffolding, all you have to do is rotate them to ensure that access is lost.
3. If using deploy tokens, you can provide them via an env variable at build time which is provided by your CI and lost in the final image.
4. If you want the image to be built, the build process needs access to the code. That's something that you just cannot avoid.
5. Private code for a project is mostly found inside its private folder, which is included in the scaffolding's git history for the sake of easiness.
6. Code that can be shared among projects is better open sourced and contributed to OCA, so open source more code and you'll have less problems like these to deal with :stuck_out_tongue:

[theangryangel]

Thanksa gain @Yajo, much appreciated :) <3

Code that can be shared among projects is better open sourced and contributed to OCA, so open source more code and you'll have less problems like these to deal with stuck_out_tongue

Yeah I'm working on that one :sweat_smile:

[yajo]

Yeah I'm working on that one sweat_smile

It's sad that my last talk in OCA code sprint wasn't recorded, but one of the points I said is that thanks to Doodba, in Tecnativa our workflow is now PR-first.

For us, it's way easier to open the PR and add that single line to our repos.yaml file, so the first thing we do is open the PR, and then later it lands in production downstream. This helps gathering benefits of open source contribution since the 1st minute in your workflow, as you benefit from all the CI and reviews in OCA, sometimes before your code is in production.

As of today, @Tecnativa has more than 2800 PRs in less than 4 years of existence, and that's a side effect of using Doodba (among other things like company culture, of course). Just go for it! :muscle:

[theangryangel]

Unfortunately it's largely a political issue for me :/ Our terms weren't particularly clear for the first large client and there's going to be a bit of back and forth. All of the fun of learning in our 12 months of operation :) I've got a few modules I'm looking to get back into either the OCA or open source generally, but it's just getting to that point right now. The next client I'm looking at doing things differently, which should help - but if you have tips I'm all for learning :smile:

[yajo]

My tips are:

• Use a own scaffolding just for developing. Mine is in https://github.com/Yajo/doodba-devel in case it serves you as inspiration. It's completely dirty and only for in-house development.
• Publish changes to OCA ASAP.
• Then your integration environments just contain private code and good repos.yaml + addons.yaml definitions.
• And of course start by having a good CI/CD pipeline. Gitlab + https://github.com/Tecnativa/doodba-qa should be a good combination.