Task #2351
closed
Change downstream bug state when upstream transitions to MODIFIED
100%
Description
The redmine_bugzilla.py automation [0] posts comment updates onto downstream issues when the upstream issue has its state change.
We need to extend that section of code to cause the state of the downstream bug to transition to POST when the upstream bug first transitions to MODIFIED. The updating of the state of the downstream bug should only be allowed if it is NEW or ASSIGNED. Once a downstream bug is at MODIFIED+ it would be inappropriate for us to update its state.
Updated by bmbouter over 7 years ago
We should also watch out for the case when an upstream bug goes from MODIFIED -> NEW or MODIFIED -> ASSIGNED. In these cases should we update the downstream bug state to be back at NEW? Or maybe we should post a comment?
Updated by bmbouter over 7 years ago
- Sprint Candidate changed from No to Yes
Here is an outline of the logic we could use. The thinking is based on the statement that downstream issues can only be at POST or later if upstream issue is at MODIFIED or later. If upstream issues go to MODIFIED but then regress back to POST or earlier we probably need to get a human involved. Also this code only transitions to the POST state so it's scope is limited, which I think is good.
if upstream==MODIFIED+ and downstream==[NEW | ASSIGNED]:
set downstream BZ to POST
if downstream==POST+ and upstream==POST-:
e-mail someone because this probably isn't right
MODIFIED+ = [MODIFIED | ON_QA | VERIFIED | CLOSED - CURRENTRELEASE]
POST+ = [POST | MODIFIED+]
POST- = [NEW | ASSIGNED | POST]
Updated by bmbouter over 7 years ago
All non-closed sat6 BZs that are associated with an upstream Pulp issue are here[0]. All of these need to be verified that they also don't need additional downstream changes. If additional downstream changes are needed, a separate issue needs to be created and associated being blocked.
This is the list of sat6 BZs that will all transition to POST the first time this is run. These should all probably be at POST already, but we can verify the automation with this.
[0]: http://tinyurl.com/jlze4vg
[1]: http://tinyurl.com/j6kyo2j
Updated by jsherril@redhat.com over 7 years ago
Would it be possible to check the downstream bug to see if there is an attached upstream foreman/katello issue? and if so do not move it to POST?
Updated by bmbouter over 7 years ago
I'm going to run a few tests to see how complex checking that would be. I'll post back here on the bug.
Updated by bmbouter over 7 years ago
@jsherrill yes I believe we can accomidate this request.
Can you link me to some examples where those trackers are present?
Updated by bmbouter over 7 years ago
- Sprint/Milestone set to 29
Bringing on the sprint per IRC conversation in #pulp-dev
Updated by bmbouter over 7 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to bmbouter
Updated by bmbouter over 7 years ago
@jsherrill I don't think the Pulp automation can incorporate information on the foreman tracker because the foreman issue state is not being recorded on the bugzilla's "external bug". Without that changing we would also need to query the upstream foreman tracker for each bug which is a lot more complex than I can support.
For example this bug[0] has an external foreman bug, but it's state is NONE even though the upstream issue is 'Ready For Testing'. All of them look this way, for example here is another one[1].
We can (and should) enable this, but foreman would need to take the next step. The upstream/downstream automation would need to start to propagate the upstream foreman bug state to the downstream external bug state. Note the external bug state is not the same as the bug state itself. Pulp does this already for Pulp bugs in this code[2] for example. Feel free to base your implementation off of that example.
The design I'm implementing is coming with an if-statement branch to handle this case but it is going to no-op for the time being.
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1388631
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1354631
[0]: https://github.com/pulp/pulp_packaging/blob/aac1db3656fe7e314ee4223e7556b9a26a82968c/ci/redmine_bugzilla.py#L128-L146
Updated by bmbouter over 7 years ago
- Status changed from ASSIGNED to POST
PR available at: https://github.com/pulp/pulp_packaging/pull/252
Updated by jsherril@redhat.com over 7 years ago
Actually i just meant the presence of a foreman issue on the BZ preventing your script from managing the bz state. This way we can hopefully handle the situation of a change needed in both katello and pulp and prevent the bz going to on_qa before its ready.
Updated by bmbouter over 7 years ago
@jsherrill, after checking with @bbuckingham we decided to enable the feature as you clarified in comment 16
Added by bmbouter over 7 years ago
Updated by bmbouter over 7 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset packaging:2ead2b425df249dfe4097a0250dcefb56d46b0db.
Updated by bmbouter over 7 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
This change is now live.
.
Updates downstream bug state
This puts several changes in place:
The downstream bug state is transitioned to POST when the upstream bug is at MODIFIED+.
If the downstream bug is at POST+ and the upstream bug is at POST- it fails the job which notifies a human.
Logic to ignore transitioning a downstream bug if there is a Foreman issue associated with it.
Some small fixes where lines were > 100 chars.
Some small docs improvements
https://pulp.plan.io/issues/2351 closes #2351