Draft
Conversation
Module to manage data regarding the migration of modules from one branch to another: - what has to be migrated - migration PR that could be reviewed - commits/PRs present on source branch but not on target branch
And handle GitHub token.
We do not want to scan some modules and attach them to a repository as while they have the same name among different projects, they do not share the same code and are specific to a project. Such modules are for instance: - studio_customization (generated by Studio in Odoo Enterprise) - server_environment_files (created manually by developers to leverage server_environment module features)
… through a context key
RepositoryScanner jobs could be quite long to execute on a repository (like 'odoo/odoo'), and depending on your Odoo config or your monitoring tools, such job could get killed before it ends up its work. While there is no issue to get the RepositoryScanner job killed and restarted later, it'll re-analyze the branch to scan to detect again the modules it has to scan, and this process itself could take ages before it re-starts the scan of the modules themselves. This commit is splitting these two tasks: - one job to detect modules to scan for a given repository/branch - one job created for each module to scan All of these jobs are depending on each other so we ensure that they are run sequentially (one branch after another, and one module after another) so only one job is running for a given repository at a time. We also ensure that no more than one job can be spawned by the user from UI. This results in a higher number of jobs, but scanning can be recovered easily.
MigrationScanner jobs could be quite long to execute on some repositories, and depending on your Odoo config or your monitoring tools, such job could get killed before it ends up its work. This commit is splitting these two tasks: - one job to scan a migration path for a given repository (that will create one job per module needing a migration scan) - one job created for each module to scan Migration scan jobs depends on the last repository scan job, as we need this one to be finished to know the list of modules that would need a migration scan.
Once a module is fully ported/migrated on the target branch, the `results` key is empty, as such the state has to be updated to 'Fully Ported'.
This change allows to get a module `x` present in different
repositories (unicity constraint on `odoo.module.branch` has changed
accordingly). This is useful in case two projects have `x` installed but
the code of these modules (that can be different) are hosted in their
own project repository.
Therefore, the scan of repositories and project modules import have been
adapted to fullfil this new possibility.
Features:
- allows multiple instances of `<odoo.module.branch>` records
sharing the same module technical name and branch but belonging to
different repositories,
- repositories have now a new `specific` flag, propagated to their
modules.. By default they host generic modules, but project repositories
will host specific modules that cannot be shared to other projects,
- a generic module cannot depend on a specific module
- when importing modules in a project, specific modules of other
projects cannot be mapped,
- once a specific module is scanned in a project repository, relevant
orphaned modules installed in a project will be re-mapped to this newly
created specific module,
- detect PR only on generic modules (unmerged/pending modules are
generic only, specific modules have to be found in project
repositories).
Remove migration path that doesn't match branches scanned in the repository (e.g. 18.0 branch could be missing in a repo while a migration path 16.0 -> 18.0 is configured, so no need to do a migration scan in this case).
…n path And change the method/button 'action_force_scan' to 'action_scan'. Thanks to the new way jobs are spawned (PR OCA#53) and the new `<odoo.module.branch>.migration_scan` flag, there is no need to reset the last scanned commits to perform a migration scan on relevant modules, preserving a lot of computation time and resources.
E.g this allows to cross modules common to different projects, to share the costs between them regarding a migration.
…ories
This supports the migration scan for modules that have been moved to
another repository.
This commit also adds new technical flags and migration states to
improve module qualification during a migration:
- Moved to standard
- Moved to OCA
- Moved to generic repo (specific modules moved to generic repo)
Migration with such states won't trigger a migration scan as modules
could be different. E.g. 'l10n_eu_oss' Odoo module is not the same than
OCA one starting from 15.0, and OCA renamed its module 'l10n_eu_oss_oca' from
this version, either to complete std implementation, or to propose
another one. So these states will help integrators to identify such
modules.
Later we could add a feature to set a given module as renamed from a
given version, like 'l10n_eu_oss' renamed to 'l10n_eu_oss_oca', so the
module won't be qualified with 'Moved to standard' state as it's just a
renaming. But such feature will require to also improve 'oca-port' to
handle such case to perform a migration scan.
…laced for next Odoo version Adapt odoo_project_migration accordingly, and show this info in CSV migration report.
…ories Now that multiple Odoo versions/branches can be set on a specific repository, we are able to collect the migration data of specific modules hosted in it.
Bugfix following-up commit 39e6bd2.
OCA repositories do not have external IDs anymore.
sebalix
force-pushed
the
18.0-mig-odoo_repository_migration
branch
from
b411da1 to
58a0b8d
Compare
sebalix
force-pushed
the
18.0-mig-odoo_repository_migration
branch
from
58a0b8d to
a901041
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.