[19.0][IMP] base: Load additional renames/merges from env.

[david-banon-tecnativa]

With this change, merging and renaming private modules no longer needs to be done in a custom module, and now can happen at the same time as OCA modules.
To use this feature:

When running openupgrade, set the OPENUPGRADE_MERGED_MODULES and OPENUPGRADE_RENAMED_MODULES environment variables to raw JSON data containing the private renames/merges in the same format as in apriori.py .
Example OPENUPGRADE_MERGED_MODULES to merge "custom module" into "helpdesk_mgmt".
{"custom_module":"helpdesk_mgmt"}

No changes should be made on current workflows if this feature is not used.

Once this PR gets approved i'll backport to all versions of OU

@pedrobaeza @victoralmau
@Tecnativa TT63118

[hbrunn]

I would prefer to see this in openupgradelib, otherwise we have to reimplement this for every version

[pedrobaeza]

@hbrunn that's not possible, as you may call update_module_names multiple times over whole OpenUpgrade migration scripts, and add there all the injected environment variables is not correct IMO.

[hbrunn]

so add a parameter enabling this which defaults to False

[pedrobaeza]

so add a parameter enabling this which defaults to False

And we will need to modify the same each OpenUpgrade version to add here such parameter...

[hbrunn]

true, but we don't need to copy&paste a bunch of logic

[hbrunn]

another option would be to have a function in openupgrade_scripts itself that does the initial renaming and merging, which the base migration just calls, and your code happens there. that then also goes automatically to all new versions

[pedrobaeza]

OK, let's do it that way. @david-banon-tecnativa do you have clear what to do? The keyword argument can be use_environment_arg=False, and when True, and depending on merge_modules variable, read one or the other.

[pedrobaeza]

another option would be to have a function in openupgrade_scripts itself that does the initial renaming and merging, which the base migration just calls, and your code happens there. that then also goes automatically to all new versions

You wrote meanwhile I was writing the other. The problem with this suggestion is that there's no apriori.py file in openupgralib to import, so I don't think we can move such code.

[pedrobaeza]

Don't add here extra line.

[hbrunn]

/ocabot merge nobump

[hbrunn]

/ocabot merge nobump

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 19.0-ocabot-merge-pr-5765-by-hbrunn-bump-nobump, awaiting test results.

[OCA-git-bot]

@hbrunn The merge process could not start, because command git push origin 19.0-ocabot-merge-pr-5765-by-hbrunn-bump-nobump failed with output:

To https://github.com/OCA/OpenUpgrade
 ! [remote rejected]         19.0-ocabot-merge-pr-5765-by-hbrunn-bump-nobump -> 19.0-ocabot-merge-pr-5765-by-hbrunn-bump-nobump (cannot lock ref 'refs/heads/19.0-ocabot-merge-pr-5765-by-hbrunn-bump-nobump': reference already exists)
error: failed to push some refs to 'https://github.com/OCA/OpenUpgrade'

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[OCA-git-bot]

Congratulations, your PR was merged at 6437799. Thanks a lot for contributing to OCA. ❤️

[hbrunn]

@david-banon-tecnativa please document the env vars somewhere in https://github.com/OCA/OpenUpgrade/tree/documentation

[hbrunn]

https://github.com/OCA/OpenUpgrade/blob/documentation/docsource/040_run_migration.rst#configuration-options probably is the right place

[david-banon-tecnativa]

Ok, OMW