Support repos with conflicting addons

[rousseldenis]

https://runboat.odoo-community.org/api/v1/builds/b552cf370-23e2-4ce6-b081-f2a76e741cc9/init-log

All runboat builds are failing on 14.0 branch in sale-workflow.

@sbidoul @lmignon

[rousseldenis]

[sbidoul]

This is due to modules having the excludes key in the manifest.

runbot did handle that by parsing the travis configuration (via travis2docker) and retaining only the configuration for the first job, therefore takiing into account the INCLUDE/EXCLUDE variables.

Parsing the CI config in runboat is definitely not an option.

I currently think about two approaches to handle this:

1. trying to automatically determine a subset of compatible modules and installing them in the database, leaving it up to the user to uninstall some and install others if they want to test another subset
2. generating multiple builds for single commits

Approach 1 sounds hard to implement (well not that hard, but requires some graph analysis wizardry that should go into manifestoo)

Approach 2 first requires supporting multiple builds for a single commit. There is an embryo of that, since the build settings is a list.
Then we need to communicate to runboat the addons groups to put in each build. Which hints at some kind of .runboat.yaml at the repo root. Which opens the door to... versatility but also complexity.

There might be other approaches. Not sure what's best.

[rousseldenis]

This is due to modules having the excludes key in the manifest.

runbot did handle that by parsing the travis configuration (via travis2docker) and retaining only the configuration for the first job, therefore takiing into account the INCLUDE/EXCLUDE variables.

Parsing the CI config in runboat is definitely not an option.

I currently think about two approaches to handle this:

1. trying to automatically determine a subset of compatible modules and installing them in the database, leaving it up to the user to uninstall some and install others if they want to test another subset
2. generating multiple builds for single commits

Approach 1 sounds hard to implement (well not that hard, but requires some graph analysis wizardry that should go into manifestoo)

Approach 2 first requires supporting multiple builds for a single commit. There is an embryo of that, since the build settings is a list. Then we need to communicate to runboat the addons groups to put in each build. Which hints at some kind of .runboat.yaml at the repo root. Which opens the door to... versatility but also complexity.

There might be other approaches. Not sure what's best.

What was the process in runbot ?

Shouldn't we in that case see case by case if those kind of modules should be in separate repos (but there can be limitations)?

[sbidoul]

What was the process in runbot ?

Have you read what I wrote ? runbot did handle that by...

Shouldn't we in that case see case by case if those kind of modules should be in separate repos (but there can be limitations)?

That is another option, but incompatible modules in the same repo is moderately frequent in OCA, even if they are not explicitly declared as such in their manifests.

[rousseldenis]

Have you read what I wrote ? runbot did handle that by...

Missed that part 😶‍🌫️

[petrus-v]

Haven't follow that much CI OCA improvement last few years, @sbidoul does the goal of runboat to replace runbot and travis ? I've the feeling that things are tested twice !

A bad option could be to ignore some modules (at least in the mean time)... but this will open the doors of bike-shading !

Matrix build defined in config file seems a nice improvement that could be used for other purpose ! Wondering if there are an easy things to do in the mean time to leave Green PR in the mean time in such case ?

[rousseldenis]

@sbidoul does the goal of runboat to replace runbot and travis ?

The goal was to replace only runbot as it was quite difficult to maintain and was based on non-standard flows.

Travis will remain obviously for tests

[sbidoul]

does the goal of runboat to replace runbot and travis ? I've the feeling that things are tested twice !

Runboat is not for running tests. Only installation for manual testing.

Travis is being replaced by GitHub actions for running tests and linters.

[petrus-v]

Oh sorry haven't takes time to deep into details this happens while installing modules 🤔

And my proposal is some how what runbot is doing today with explicit configuration which you would like to avoid as far I understand !

Thanks for details and all massive works, I've to investigate more to tell something clever on the topic sorry for the nose !

[sbidoul]

@petrus-v no worries! I hope I did not come across as dismissive, it certainly was not my intent.

[sbidoul]

If we decide to implement a .runboat.yaml with an addons matrix, the question of naming the matrix elements will come up. Currently in the oca-addons-repo-template, the copier question about rebel module groups does not ask to name the groups.

Also the matrix would need to be combined with build settings names to create build names.

The names will need to be short enough to reasonably fit in the build cards in the UI.

[petrus-v]

@petrus-v no worries! I hope I did not come across as dismissive, it certainly was not my intent.

I don't feel you were dismissive :). You are very patient and I'm amazed with all you're doing.