Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix followups of detached PRs when disabling branch #897

Closed
xmo-odoo opened this issue Jun 21, 2024 · 0 comments
Closed

fix followups of detached PRs when disabling branch #897

xmo-odoo opened this issue Jun 21, 2024 · 0 comments

Comments

@xmo-odoo
Copy link
Collaborator

This process was already reworked with 94fe032 but it looks like by going through _schedule_fw_followup I missed a massive issue: detached PRs are skipped, so if a FW sequence ends with a detached PR (conflict, modified) and that PR's target is disabled, the sequence is lost. Instead the forward porting should be forced (at least on that ground, it should still take stuff like limits in account).

Furthermore there are issues when trying to recover from this:

  • batches can't be looked up by name (label) so imports are not really possible (as lookup by id is not really an import thing)
  • the default view for forward port jobs is a non-editable list (there are only two fields, three if including the PR to complete batches so should be an editable list for sure)
  • there seem to be some odd behaviour when trying to a forwardport job for a PR which is closed and / or has a limit unset: while trying to recover from that after the deactivation of 16.3 and 16.4 I got complains about no next target and about the fw sequence being done (the latter of which normally makes sense, if we close a PR we don't want it to port forward, guess it still makes sense in case statuses succeed, the batch is scheduled for fw, and we close the PRs before that actually happens)
xmo-odoo added a commit that referenced this issue Jun 28, 2024
Although the handling of forward ports on disabled branch was improved
in 94fe032 in order to avoid losing
or needing to manually port such, because it goes through
`_schedule_fw_followup` some of the tests *that* performs were missed,
most notably that it only ports batches when no PRs are detached.

This is an issue if we need to force the port because of a branch
being deactivated: the forward-port could have stopped there due to a
conflict, in which case it's always going to be detached.

Thus the `force_fw` flag should also override the parenting state
check.

Also while at it make `force_fw` a regular flag, I don't understand
why I made it into a context value in the first place, it's only
passed from one location and that's directy calling the one function
which uses it...

Fixes #897
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: done
Development

No branches or pull requests

1 participant