[ADD] New tool: oca-port #504

sebalix · 2021-07-29T08:03:03Z

Tool helping to port an addon or missing commits of an addon from one branch to another.

/!\ It requires Python 3.8. /!\

If the addon does not exist on the target branch, it will assist the user in the migration, following the OCA migration guide.

If the addon already exists on the target branch, it will retrieve missing commits to port. If a Pull Request exists for a missing commit, it will be ported with all its commits if they were not yet (fully) ported.

To check if an addon could be migrated or to get eligible commits to port:

$ export GITHUB_TOKEN=<token>
$ oca-port 13.0 14.0 shopfloor --verbose

To effectively migrate the addon or port its commits, use the --fork option:

$ oca-port 13.0 14.0 shopfloor --fork camptocamp

Migration of addon

The tool follows the usual OCA migration guide to port commits of an addon, and will invite the user to fullfill the mentionned steps that can't be performed automatically.

Output example:

Port of commits/Pull Requests

The tool will ask the user if he wants to open draft pull requests against the upstream repository.

If there are several Pull Requests to port, it will ask the user if he wants to base the next PR on the previous one, allowing the user to cumulate ported PRs in one branch and creating a draft PR against the upstream repository with all of them.

Output example (with --verbose):

Some details:

commits history has to be preserved to get this tool working properly: commits equality is checked against a list of attributes like the author name/email, the authored utc datetime, the message... but not the SHA as it changes from one branch to another (so if a ported commit has been amended to change a bit the message, the commit will be considered as not ported, generating false positive)
merge commit and translations ones are skipped (checking the commit message/author)
we could have an original commit updating two addons A and B, and an existing ported commit done in the past through git format-patch only for one of the addons e.g. A, so the commit will still be considered as eligible to be ported by this tool. If two ported commits exist (each updating one addon, A then B), the commit will then be considered as already ported
port is performed with git format-patch, if a conflict appears, the process will wait the user to resolve it before continuing the cherry-pick, and so on.
GitHub token should be set in the GITHUB_TOKEN env var

====
It is still a draft, for now I only tested it on OCA/wms on a bunch of addons.

TODO:

rousseldenis · 2021-07-29T08:13:11Z

Great!

sebalix · 2021-07-29T13:40:56Z

Live test on OCA/server-backend for base_user_role module: OCA/server-backend#130

sebalix · 2021-07-30T10:04:08Z

Some PRs generated: https://github.com/OCA/wms/pulls?q=is%3Apr+is%3Aopen+oca-port-pr

rousseldenis · 2021-08-05T08:02:16Z

@sebalix

In some local git configurations, origin is not configured as OCA (changed easily of course).

But shouldn't be good to have also both remotes as argument ?

rousseldenis · 2021-08-05T08:03:49Z

And ten millions dollars question, shouldn't it be great to select PRs to port with a choice in case of multiple ?

UPDATE: ooooh, didn't see further commands. Ok, I test furthermore

rousseldenis · 2021-08-05T08:35:34Z

Tested there : OCA/search-engine#98

Seems good for me

sebalix · 2021-08-05T08:36:18Z

@rousseldenis we can change the OCA remote with the --upstream option.
~~The tricky thing about the fork is, to not have a lot of options, I stuck to the idea "local remote name == fork org name", maybe I should change that and add an option to separate this.~~ (EDIT: I added the --user-org option in the meantime, default on --fork)

About porting several PRs at the same time, I'm thinking about it. Often, one PR depends on a previous one (that's why the list of PRs are sorted by merge date), and I was thinking about proposing to the user to base the next PR on the branch of the last ported one, or make it by default... I really don't know how to handle that. It is difficult to know if a PR really depends on a previous one to avoid merge conflicts, and sometime PRs could be merged independently so introducing a dependency between them will just make more noise.

simahawk · 2021-08-05T10:40:44Z

1st of all: this feature is amazing. Thanks!

My POV (as we discussed together): we should improve it to make it THE module migrator and fwd/back porter. I would:

rename it to oca-port (is not just about a bunch of PRs)
rip out of odoo-module-migrator everything but the tasks for making modules compat w/ the target version
run odoo-module-migrator at the end of the process

As we discussed, using it for migration would require "only" to:

auto-detect that the module is new (via checking the diff type)
based on this use the same for all PRs and not ask to port each PR singularly
use one single branch (called -mig- instead of *-pr-$number-*

Finally one more feature could be: finding pending PRs before migrating. Meaning that the tool could say "hey, there's a pending PR that you could help review/merge that could be included in the migration". Or something like that.
This way we would avoid the typical request like "ah, there's this fix/imp that would be nice to include can you cherry-pick?"
For version 2.0 maybe... 😄

pedrobaeza · 2021-08-05T14:37:54Z

Thanks for this tool. Note that the guideline for the PR title is

[<version>][<type>] <module>: <short explanation>

Example: [14.0][FIX] date_range: Fix search

Thus, several comments about the PR title format.

Putting [13.0->14.0] at the beginning, changes this guideline. Put only the target branch.
The same happens with [oca-port-pr-#171], that should be out IMO.

I think both information should be on the main comment instead of being part of the title. We can suffix (or prefix) the PR with a similar formula like Odoo does, putting something short like (FW).

sebalix · 2021-08-05T15:03:00Z

@pedrobaeza is a PR title [14.0][PORT] {addon}: {title} acceptable? As it can be difficult to guess what the original PR is about (FIX, IMP, ADD, MIG, REF...), unless by parsing a lot original PR title but it begins to be quite complex. Or [14.0][FW] {addon}: {title}?

pedrobaeza · 2021-08-05T15:32:50Z

If you are parsing the module, why is it more difficult to parse the rest of the previous title?

Anyways, in such case, I think it becomes more acceptable this mask: [14.0][FW] <title>, so the original PR title being [12.0][FIX] date_range: Fix search, and fw-port it to 14.0, will result in [14.0][FW] [12.0][FIX] date_range: Fix search, and we have both source and target branch, and let the contributor to set the rest of the title more freely.

sebalix · 2021-08-05T15:39:54Z

Because it's easier to wipe out things between brackets and version numbers from the original title, then adding our own suffixes afterward :)
But a possibility is to only remove version numbers from the original PR title (e.g. 13.0 or [13.0]) and keep all the rest, that means the new PR title could be:

[14.0][MIG] ...
[14.0] mig ... (like there: 14.0 mig stock picking sale order link stock-logistics-workflow#861)
[14.0] ... (without any suffix)
And up the the user or PSC members to rename the PR afterwards.

EDIT: your suggestion is also a good one...

pedrobaeza · 2021-08-05T17:08:11Z

I think it can be valuable to keep whole title for knowing the source, as you can do a patch in 12.0, and want to fw-port it to 13.0 and 14.0 (well, black will provoke incorrect PR for sure in this case, but I am exposing it as example). I let you the final word, as you are the one doing the work.

Other things that come to my mind now that I have dived a bit more in the PR:

On the command line itself, don't you think it's better to do have oca-port-pr 13.0 14.0 --addon shopfloor_packing_info. We lose the possibility of altering order, but we gain on number of characters to type.
If there's any conflict applying the patch, whole process can be resumed by any way?
Isn't overlapping a bit with oca-module-migrator commit extraction part (saving the translation and administrative commits part)?
Other option can be to integrate it on ocabot for launching the fw-ports from a comment in the original PR:

ocabot fw-port up-to 13.0

Cons of this:
- PRs will be created under OCA branches with no possibility of changing them.
- Conflicts may arise with no possibility of amending them without forking.

sebalix · 2021-08-06T07:43:14Z

@pedrobaeza

I think it can be valuable to keep whole title for knowing the source, as you can do a patch in 12.0, and want to fw-port it to 13.0 and 14.0 (well, black will provoke incorrect PR for sure in this case, but I am exposing it as example). I let you the final word, as you are the one doing the work.

We could do that indeed. It begins to be tricky if we want to forward port a PR on the two next versions (and we start on the previous one to make the next, so the title will be very long), but I think it is rare and we could still rename the PR afterwards. I'm also looking for existing PR created by this tool based on its name, but it seems GH is keeping previous PR values somewhere because I could still find the PR through GH API even with its old name. So let's do this simple for the moment with [14.0][FW] {original_title}.

On the command line itself, don't you think it's better to do have oca-port-pr 13.0 14.0 --addon shopfloor_packing_info. We lose the possibility of altering order, but we gain on number of characters to type.

Good idea, I'll do that.

If there's any conflict applying the patch, whole process can be resumed by any way?

If a conflict appears, the process will wait (as shown in the output example in the PR description), the user will have to resolve the conflict the normal way (finishing the resolution either with a git am --continue or git am --skip) and resume the process.
If he left the process then no, there is at the moment no option to restart the work on a given PR.

Isn't overlapping a bit with oca-module-migrator commit extraction part (saving the translation and administrative commits part)?

We discussed about that with @simahawk (see its comment above), later this tool could replace odoo-module-migrator for the part related to git format-patch, but it would still be needed then to adapt the code to the targeted branch, at the end they will be complementary.

Other option can be to integrate it on ocabot for launching the fw-ports from a comment in the original PR:
ocabot fw-port up-to 13.0
Cons of this:

PRs will be created under OCA branches with no possibility of changing them.

Conflicts may arise with no possibility of amending them without forking.

Indeed, @gurneyalex whispers me this idea some weeks ago. Good catch about access rights, and sometime we have to resolve small conflicts (because of pre-commit changes for instance) so it's not easy to get a complete automatic flow here.

sebalix · 2021-08-06T13:50:07Z

Last feature: Use the previous PR #126 branch as base?
Example here: OCA/wms#270

$ oca-port-pr 13.0 14.0 --addon stock_available_to_promise_release --fork camptocamp
Fetch origin/13.0 from git://github.com/OCA/wms.git
Fetch origin/14.0 from git://github.com/OCA/wms.git

7 pull request(s) related to 'stock_available_to_promise_release' to port from origin/13.0 to origin/14.0

- PR #104 (https://github.com/OCA/wms/pull/104) [FIX] shopfloor: cluster picking, remove unavailable picking from validated batch:
	By sebalix, merged at 2021-01-13T09:10:57Z
	=> Not ported: ['stock_available_to_promise_release']
	=> 1 commit(s) not (fully) ported
- PR #94 (https://github.com/OCA/wms/pull/94) [13.0][FIX] 'Release ready' based on the shipping policy of the order:
	By sebalix, merged at 2021-01-13T11:53:40Z
	=> Not ported: ['stock_available_to_promise_release', 'sale_stock_available_to_promise_release']
	=> 1 commit(s) not (fully) ported
- PR #116 (https://github.com/OCA/wms/pull/116) [13.0] stock_available_to_promise_release: Change test case helper methods as classmethod:
	By guewen, merged at 2021-01-14T14:08:03Z
	=> Not ported: ['stock_available_to_promise_release']
	=> 1 commit(s) not (fully) ported
- PR #106 (https://github.com/OCA/wms/pull/106) stock_available_to_promise_release: Fix quantity available to promise of released moves:
	By jbaudoux, merged at 2021-01-14T14:40:11Z
	=> Not ported: ['stock_available_to_promise_release']
	=> 2 commit(s) not (fully) ported
- PR #126 (https://github.com/OCA/wms/pull/126) [13.0] stock_available_to_promise_release: Fix horizon - count released move outside horizon:
	By jbaudoux, merged at 2021-01-21T12:48:02Z
	=> Not ported: ['stock_available_to_promise_release']
	=> 2 commit(s) not (fully) ported
- PR #173 (https://github.com/OCA/wms/pull/173) [13.0] Add shopfloor_workstation + sync w/ OCA/oca-addons-repo-template:
	By simahawk, merged at 2021-02-12T01:48:18Z
	=> Not ported: ['CONTRIBUTING.md', '.pylintrc-mandatory', 'README.md', 'stock_move_source_relocate_dynamic_routing', '.travis.yml', 'stock_reception_screen', 'stock_available_to_promise_release', 'oca_dependencies.txt', 'sale_stock_available_to_promise_release', '.prettierrc.yml', 'requirements.txt', '.pre-commit-config.yaml', '.github', '.copier-answers.yml', 'LICENSE', '.pylintrc', '.gitignore', 'shopfloor_workstation', 'setup']
	=> 4 commit(s) not (fully) ported
- PR #174 (https://github.com/OCA/wms/pull/174) [13.0] stock_available_to_promise_release: Fix release of operation containing canceled moves:
	By sebalix, merged at 2021-02-17T16:31:31Z
	=> Not ported: ['stock_available_to_promise_release']
	=> 2 commit(s) not (fully) ported

- Port PR #104 (https://github.com/OCA/wms/pull/104) [FIX] shopfloor: cluster picking, remove unavailable picking from validated batch...
	Port it? [y/N]: y
	Create branch oca-port-pr-104-from-13.0-to-14.0 from origin/14.0...
		Apply ee928218552708328cd4bf0026045de4d25abf5f [FIX] stock_available_to_promise_release: fix flappy test...
	Push branch 'oca-port-pr-104-from-13.0-to-14.0' to remote 'camptocamp'? [y/N]: 
- Port PR #94 (https://github.com/OCA/wms/pull/94) [13.0][FIX] 'Release ready' based on the shipping policy of the order...
	Port it? [y/N]: y
	Use the previous PR #104 branch as base? [y/N]: y
	Create branch oca-port-pr-94-from-13.0-to-14.0 from oca-port-pr-104-from-13.0-to-14.0...
		Apply 5342da2d84b7d487815611e423be2a10e3280b94 [FIX] 'Release ready' based on the shipping policy of the order...
	Push branch 'oca-port-pr-94-from-13.0-to-14.0' to remote 'camptocamp'? [y/N]: 
- Port PR #116 (https://github.com/OCA/wms/pull/116) [13.0] stock_available_to_promise_release: Change test case helper methods as classmethod...
	Port it? [y/N]: y
	Use the previous PR #94 branch as base? [y/N]: y
	Create branch oca-port-pr-116-from-13.0-to-14.0 from oca-port-pr-94-from-13.0-to-14.0...
		Apply 6c7587a4188a4de24216110c19027c81c22d6a0d Change test case helper methods as classmethod...
	Push branch 'oca-port-pr-116-from-13.0-to-14.0' to remote 'camptocamp'? [y/N]: 
- Port PR #106 (https://github.com/OCA/wms/pull/106) stock_available_to_promise_release: Fix quantity available to promise of released moves...
	Port it? [y/N]: y
	Use the previous PR #116 branch as base? [y/N]: y
	Create branch oca-port-pr-106-from-13.0-to-14.0 from oca-port-pr-116-from-13.0-to-14.0...
		Apply 9ac87637c17d0291862027000e3124fbe8b93a01 stock_available_to_promise_release: Fix quantity available to promise of released moves...
		Apply 0c57c0fc2d405b332bfc38affd557d3309bf5776 stock_available_to_promise_release: Fix moves for which available to promise is computed...
	Push branch 'oca-port-pr-106-from-13.0-to-14.0' to remote 'camptocamp'? [y/N]: 
- Port PR #126 (https://github.com/OCA/wms/pull/126) [13.0] stock_available_to_promise_release: Fix horizon - count released move outside horizon...
	Port it? [y/N]: y
	Use the previous PR #106 branch as base? [y/N]: y
	Create branch oca-port-pr-126-from-13.0-to-14.0 from oca-port-pr-106-from-13.0-to-14.0...
		Apply bc0d4dd7173acbed823fac71e93a9c43ba27e5f5 stock_available_to_promise_release: when a move is released, it must be counted in the stock previously promised even when it is outside horizon...
		Apply dbb9d7c6c1494d2b58ac55cacd755f728b3d81d4 Fix update of quantity in tests...
	Push branch 'oca-port-pr-126-from-13.0-to-14.0' to remote 'camptocamp'? [y/N]: 
- Port PR #173 (https://github.com/OCA/wms/pull/173) [13.0] Add shopfloor_workstation + sync w/ OCA/oca-addons-repo-template...
	Port it? [y/N]: 
- Port PR #174 (https://github.com/OCA/wms/pull/174) [13.0] stock_available_to_promise_release: Fix release of operation containing canceled moves...
	Port it? [y/N]: y
	Branch oca-port-pr-174-from-13.0-to-14.0 already exists, recreate it? 
	(WARNING: you will lose the existing branch) [y/N]: y
	Use the previous PR #126 branch as base? [y/N]: y
	Create branch oca-port-pr-174-from-13.0-to-14.0 from oca-port-pr-126-from-13.0-to-14.0...
		Apply d2bd0b89535e1d287fe6d0073029d416bb1aab85 Fix release of operation containing canceled moves...
		Apply 7c95bdca1272b8c88c1044b9eb28dca93279c093 Fix release of operation containing canceled moves (test)...
	🎉 Last PR processed! 🎉
	Push branch 'oca-port-pr-174-from-13.0-to-14.0' to remote 'camptocamp'? [y/N]: y
	PR(s) ported locally: #104, #94, #116, #106, #126, #174
	Create a draft PR from 'oca-port-pr-174-from-13.0-to-14.0' to '14.0' against OCA/wms? [y/N]: y
		PR created => https://github.com/OCA/wms/pull/270

sbidoul · 2021-12-15T09:03:17Z

I've not had a chance to try it but I like the concept.
Have you considered creating a standalone project for it ? Because maintainer-tools is a bit of a mess...

simahawk · 2021-12-15T11:22:49Z

I've not had a chance to try it but I like the concept. Have you considered creating a standalone project for it ? Because maintainer-tools is a bit of a mess...

I agree and TBH I'd prefer to have a separate project. Then MT could be just a bundle of them w/ some default conf maybe.
@sebalix what do you think?

sebalix · 2021-12-15T11:31:34Z

@simahawk I agree, it'll also helps to show a quick user documentation in a README like the description of this PR.

simahawk · 2021-12-15T11:32:55Z

@simahawk I agree, it'll also helps to show a quick user documentation in a README like the description of this PR.

cool, I'll setup a new repo when you are ready

pedrobaeza · 2021-12-15T15:54:37Z

The option to include this in module-migrator has been discarded?

dreispt · 2021-12-15T18:59:16Z

Maybe we need "OCA/contributor-tools" ?

…

On 15/12/21 15:54, Pedro M. Baeza wrote: The option to include this in module-migrator has been discarded? — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#504 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQLJPQW5TOZAUZCOUUVGLURC24RANCNFSM5BF5ODGA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

simahawk · 2021-12-16T08:44:00Z

The option to include this in module-migrator has been discarded?

What this tool does is a different work. It's not migrating modules where "migrating" means "adapt the code to a newer of older version of Odoo". It eases back/fwd porting of PRs and commits.

I would keep it separated and we could integrate the migrator as a feature later. This feature could be installed optionally by the user like pip install oca-port[migrator].

hparfr · 2021-12-29T13:48:16Z

Thanks for this tool @sebalix.

I have tested it against field-service for porting merged PR.
oca-port 12.0 14.0 fieldservice --verbose --fork akretion

Perf:
More progression feedback can be good. It took 10min to run on my machine the first time. Then I got API limit issues (because I didn't properly pass github token).

BranchesDiff() takes ~25seconds before the first request.

Issues:

False positives: 40ish ports were proposed to be done but were already merged. The blacklist was then a lifesaver.
With all ports created with this tool, I always had merge conflicts. — do not know if it was expected.
At the end of some ports, I was unable to continue because of trackeback: RuntimeError: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"No commits between OCA:14.0 and akretion:oca-port-pr-850-from-12.0-to-14.0"}],"documentation_url":"https://docs.github.com/rest/reference/pulls#create-a-pull-request"} or stderr: 'fatal: previous rebase directory .git/rebase-apply still exists but mbox given.' or stderr: 'fatal: Resolve operation not in progress, we are not resuming.'. — Just had to go back to a stable git state, then re-run oca-port
When re-run oca-port, already port done by me some minutes ago, pushed but not merged are suggested. — may be skip them if a branch named by oca-port already exists on the remote or local.

Features I miss be able to target a precise (known) PR

Note that the guideline for the PR title is
[<version>][<type>] <module>: <short explanation>
Example: [14.0][FIX] date_range: Fix search
The same happens with [oca-port-pr-#171], that should be out IMO.
I think both information should be on the main comment instead of being part of the title.

Do not agree: having the original PR number in the name can help to track the progression.
ie: [14.0][FW] [12.0][FIX] date_range: Fix search #171

Being able to commit this file would be nice in the future (if this tool is merged), is there a blocking point to do that?

There a distinction between (shared knowledge): the PR should not be merged (because it's false positive, a dead feature, not needed anymore...) and (local) I do not want to work on this PR now and do not want to be asked again next time.

Conclusion: Really nice tool, I think it's good enough yet to be merged (or put on his own repo).

OCA-git-bot · 2021-12-29T14:00:03Z

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). 🤖

sebalix · 2022-01-11T15:07:45Z

@hparfr thank you for your feedback!

Perf:
More progression feedback can be good. It took 10min to run on my machine the first time. Then I got API limit issues (because I didn't properly pass github token).

BranchesDiff() takes ~25seconds before the first request.

10min, it's quite a lot even with a lot of commits to check 🤔 But yes it is sometimes a bit slow, I tried to reduce the time needed (even by switching from GitPython to pygit2 but it was worse!). But there is space for improvements like putting some cache on disk.

With all ports created with this tool, I always had merge conflicts. — do not know if it was expected.

It is expected, especially if the code base has changed a bit because of migration commits or, more often, new format rules with pre-commit.

At the end of some ports, I was unable to continue because of trackeback:

Never encountered this one... or maybe because you didn't execute git am --continue or git am --skip once you resolved the conflicts, letting the repository in a bad state for the next commit to port?

When re-run oca-port, already port done by me some minutes ago, pushed but not merged are suggested. — may be skip them if a branch named by oca-port already exists on the remote or local.

Good idea, the tool should ask the user if they want to resume from there is there is a branch.

Features I miss be able to target a precise (known) PR

I miss it too, really a nice-to-have for the next time.

There a distinction between (shared knowledge): the PR should not be merged (because it's false positive, a dead feature, not needed anymore...) and (local) I do not want to work on this PR now and do not want to be asked again next time.

Indeed, so maybe add a comment when blacklisting a PR, and if we want to blacklist it locally, store this in a file that is .gitignored.

simahawk · 2022-01-13T14:56:14Z

Example of blacklisting to be shared OCA/edi#513

etobella

Tested locally. Seems amazing!!!

bosd · 2022-02-28T19:36:24Z

Looks like an amazing tool!!!
However, encountered a
Error: changes not committed detected in this repository.
How to solve this?

rousseldenis

@sebalix Is it scheduled to merge this ?

sbidoul · 2022-03-16T09:32:32Z

Is it scheduled to merge this

I think the plan was to move it to its own repo.

rousseldenis · 2022-03-16T09:33:24Z

Is it scheduled to merge this

I think the plan was to move it to its own repo.

Let's go ! 😃

simahawk · 2022-03-16T09:52:40Z

Hi all, thanks for testing/reviewing 🙏
We are super busy w/ some go lives 😅 We'll get back to this ASAP 😉

simahawk · 2022-07-11T09:28:06Z

@sebalix better late than never https://github.com/OCA/oca-port 😉

sebalix · 2022-08-05T12:29:49Z

This tool is now hosted on https://github.com/OCA/oca-port/, I'm closing this PR.

sebalix mentioned this pull request Jul 29, 2021

[14.0][FW] [13.0][FIX] base_user_role: Improve tests resiliency OCA/server-backend#130

Merged

sebalix force-pushed the add-oca-port-pr branch from ddd99a0 to 6e26694 Compare July 29, 2021 15:47

sebalix mentioned this pull request Jul 29, 2021

[13.0->14.0][oca-port-pr-#113] shopfloor: create backorder when validating moves OCA/wms#252

Closed

sebalix force-pushed the add-oca-port-pr branch 2 times, most recently from bdc355c to e6b58f5 Compare July 30, 2021 08:02

sebalix force-pushed the add-oca-port-pr branch from 0f8b542 to 6941b21 Compare August 2, 2021 13:09

pedrobaeza mentioned this pull request Aug 5, 2021

Fix : Don't parse onchange resullt when returning False instead of nothing OCA/connector-ecommerce#61

Merged

sebalix force-pushed the add-oca-port-pr branch 2 times, most recently from d614e68 to 6bb3751 Compare August 6, 2021 08:48

sebalix force-pushed the add-oca-port-pr branch from 221832d to 70c5d05 Compare August 6, 2021 13:54

sebalix changed the title ~~New tool: oca-port-pr~~ [WIP] New tool: oca-port-pr Aug 7, 2021

sebalix force-pushed the add-oca-port-pr branch 4 times, most recently from 9fb5274 to eba823d Compare August 11, 2021 08:31

sbidoul mentioned this pull request Dec 20, 2021

Module Migration Standard to version 15.0 OCA/mis-builder#394

Closed

pedrobaeza mentioned this pull request Dec 22, 2021

[MIG] sale_order_line_input: Migration to 14.0 OCA/sale-workflow#1815

Closed

hparfr approved these changes Dec 29, 2021

View reviewed changes

OCA-git-bot added approved ready to merge labels Dec 29, 2021

simahawk mentioned this pull request Jan 13, 2022

Add .oca-port.json OCA/edi#513

Merged

simahawk mentioned this pull request Jan 13, 2022

Add .oca-port.json OCA/connector#426

Closed

etobella approved these changes Jan 24, 2022

View reviewed changes

rousseldenis approved these changes Mar 16, 2022

View reviewed changes

GuillemCForgeFlow mentioned this pull request Apr 21, 2022

[14.0][FW]base_user_role: Groups-roles navigation OCA/server-backend#159

Merged

pedrobaeza mentioned this pull request May 26, 2022

[QUESTION][15.0] How to bring queue_job up to par with [14.0]? OCA/queue#435

Closed

simahawk mentioned this pull request Jul 13, 2022

duplicate of https://github.com/OCA/odoo-module-migrator ? OCA/oca-port#1

Closed

sebalix closed this Aug 5, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ADD] New tool: oca-port #504

[ADD] New tool: oca-port #504

sebalix commented Jul 29, 2021 •

edited

Loading

rousseldenis commented Jul 29, 2021

sebalix commented Jul 29, 2021

sebalix commented Jul 30, 2021

rousseldenis commented Aug 5, 2021

rousseldenis commented Aug 5, 2021 •

edited

Loading

rousseldenis commented Aug 5, 2021

sebalix commented Aug 5, 2021 •

edited

Loading

simahawk commented Aug 5, 2021

pedrobaeza commented Aug 5, 2021

sebalix commented Aug 5, 2021 •

edited

Loading

pedrobaeza commented Aug 5, 2021

sebalix commented Aug 5, 2021 •

edited

Loading

pedrobaeza commented Aug 5, 2021

sebalix commented Aug 6, 2021

sebalix commented Aug 6, 2021 •

edited

Loading

sbidoul commented Dec 15, 2021

simahawk commented Dec 15, 2021 •

edited

Loading

sebalix commented Dec 15, 2021

simahawk commented Dec 15, 2021

pedrobaeza commented Dec 15, 2021

dreispt commented Dec 15, 2021 via email

simahawk commented Dec 16, 2021 •

edited

Loading

hparfr commented Dec 29, 2021

OCA-git-bot commented Dec 29, 2021

sebalix commented Jan 11, 2022 •

edited

Loading

simahawk commented Jan 13, 2022

etobella left a comment

bosd commented Feb 28, 2022

rousseldenis left a comment

sbidoul commented Mar 16, 2022

rousseldenis commented Mar 16, 2022

simahawk commented Mar 16, 2022

simahawk commented Jul 11, 2022

sebalix commented Aug 5, 2022

[ADD] New tool: oca-port #504

[ADD] New tool: oca-port #504

Conversation

sebalix commented Jul 29, 2021 • edited Loading

/!\ It requires Python 3.8. /!\

Migration of addon

Port of commits/Pull Requests

rousseldenis commented Jul 29, 2021

sebalix commented Jul 29, 2021

sebalix commented Jul 30, 2021

rousseldenis commented Aug 5, 2021

rousseldenis commented Aug 5, 2021 • edited Loading

rousseldenis commented Aug 5, 2021

sebalix commented Aug 5, 2021 • edited Loading

simahawk commented Aug 5, 2021

pedrobaeza commented Aug 5, 2021

sebalix commented Aug 5, 2021 • edited Loading

pedrobaeza commented Aug 5, 2021

sebalix commented Aug 5, 2021 • edited Loading

pedrobaeza commented Aug 5, 2021

sebalix commented Aug 6, 2021

sebalix commented Aug 6, 2021 • edited Loading

sbidoul commented Dec 15, 2021

simahawk commented Dec 15, 2021 • edited Loading

sebalix commented Dec 15, 2021

simahawk commented Dec 15, 2021

pedrobaeza commented Dec 15, 2021

dreispt commented Dec 15, 2021 via email

simahawk commented Dec 16, 2021 • edited Loading

hparfr commented Dec 29, 2021

OCA-git-bot commented Dec 29, 2021

sebalix commented Jan 11, 2022 • edited Loading

simahawk commented Jan 13, 2022

etobella left a comment

Choose a reason for hiding this comment

bosd commented Feb 28, 2022

rousseldenis left a comment

Choose a reason for hiding this comment

sbidoul commented Mar 16, 2022

rousseldenis commented Mar 16, 2022

simahawk commented Mar 16, 2022

simahawk commented Jul 11, 2022

sebalix commented Aug 5, 2022

sebalix commented Jul 29, 2021 •

edited

Loading

rousseldenis commented Aug 5, 2021 •

edited

Loading

sebalix commented Aug 5, 2021 •

edited

Loading

sebalix commented Aug 5, 2021 •

edited

Loading

sebalix commented Aug 5, 2021 •

edited

Loading

sebalix commented Aug 6, 2021 •

edited

Loading

simahawk commented Dec 15, 2021 •

edited

Loading

simahawk commented Dec 16, 2021 •

edited

Loading

sebalix commented Jan 11, 2022 •

edited

Loading