[16.0][OU-ADD] base_automation: Nothing to do #3779
Conversation
|
/ocabot migration base_automation |
marielejeune
force-pushed
the
16.0-base_automation-mle
branch
from
8da140a to
4b6e08d
Compare
marielejeune
force-pushed
the
16.0-base_automation-mle
branch
from
4b6e08d to
4fef924
Compare
marielejeune
changed the title
legalsylvain
left a comment
legalsylvain
left a comment
There was a problem hiding this comment.
/ocabot merge patch
|
/ocabot merge patch |
|
Hey, thanks for contributing! Proceeding to merge this for you. |
|
What a great day to merge this nice PR. Let's do it! |
|
This PR has the |
|
@legalsylvain your merge command was aborted due to failed check(s), which you can inspect on this commit of 16.0-ocabot-merge-pr-3779-by-legalsylvain-bump-patch. After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red. |
|
/ocabot merge patch |
|
Hey, thanks for contributing! Proceeding to merge this for you. |
|
@legalsylvain your merge command was aborted due to failed check(s), which you can inspect on this commit of 16.0-ocabot-merge-pr-3779-by-legalsylvain-bump-patch. After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red. |
|
No need to launch ocabot, and less with version bumping, as there's no sense in that. Merging directly. |
We've already talked about it. Yes, I think it's important. You can disagree, but please don't say the same thing over and over again, without argument. |
|
I don't remember any counter argument on your part. |
I can't find the PR where we both talked about this subject. |
|
My reasons for not using ocabot here is for not wasting builds, as it's not adding value, except explicitly wanting to have CI on a rebased branch, which is not likely here most of the times. I merge the same manually when in another OCA repository, migration scripts are added. They are not being tested, and the linters are already tested on the PR. You, being very eco-friendly with other things, should be aware of the impact of doing all that redundant builds. Maintainers and people with enough knowledge should know when they can override a guideline for the greater good. |
|
Hi @pedrobaeza. thanks for your answer. In fact, I don't understand how you can know that the merge will sucess if the pending PR is not rebased. There are tests on Openupgrade. The module installed are based on the coverage file. So if the coverage file is not up to date (that is occures, when the PR is not rebased), you cannot guarantee the success of the merge. Well, I'm OK to stop to use the bot, as far as there is no bad side effect. Let me know if I miss something. regards. |
|
The CI may become red in anytime due to outsider conditions, but launching ocabot on pending PRs will only highlights the inner fault on the main branch, but it's not a fault of the PR itself. On OpenUpgrade, there can't be interactions between non dependent modules, as they incorporate isolated migration scripts, and the minimal existing tests only check specific operations done for the corresponding module. My goal is to launch the minimal possible CI builds. If you have a PR depending on another one due to module hierarchy, there are 2 options:
On both cases, only one CI is built. The rest is redundant. Of course this is not critical, and thousands of other CIs are launched without need, but due to the high number of PRs in this repo (this one is number 3379 - no OCA repo gets even a fraction of this number), we can make a significant difference in OCA ecosystem. |
6 participants
No description provided.