better explain ABORTED checks
ClosedPublic

Authored by kparal on May 6 2015, 12:35 PM.

Details

Summary

This adds a longer explanation when some check is aborted because of a
missing build in an update (which means that the update got edited
during the check execution). A list of such missed builds is printed
out. This should make it easier for readers to understand what's going on.

A safety check for build2update() correctness was removed, it's better
to put these safety checks directly into build2update() method.

The explanation now looks like:

not ok - depcheck for Bodhi update NetworkManager-1.0.2-1.fc22,network-manager-applet-1.0.2-1.fc22,NetworkManager-openconnect-1.0.2-1.fc22,NetworkManager-openvpn-1.0.2-1.fc22,NetworkManager-vpnc-1.0.2-1.fc22,NetworkManager-openswan-1.0.2-1.fc22    # FAIL 
  ---
  arch: i386
  details:
    output: |-
      Update was incomplete - not all builds from this update have been tested. This can happen when the update is edited in Bodhi during the check execution.
      Builds which haven't been tested:
        NetworkManager-openconnect-1.0.2-1.fc22
  item: NetworkManager-1.0.2-1.fc22,network-manager-applet-1.0.2-1.fc22,NetworkManager-openconnect-1.0.2-1.fc22,NetworkManager-openvpn-1.0.2-1.fc22,NetworkManager-vpnc-1.0.2-1.fc22,NetworkManager-openswan-1.0.2-1.fc22
  outcome: ABORTED
  summary: NetworkManager-1.0.2-1.fc22,network-manager-applet-1.0.2-1.fc22,NetworkManager-openconnect-1.0.2-1.fc22,NetworkManager-openvpn-1.0.2-1.fc22,NetworkManager-vpnc-1.0.2-1.fc22,NetworkManager-openswan-1.0.2-1.fc22
    into F22 testing
  type: bodhi_update
  ...

The safety check (everything connected to untested_builds variable) was instead put directly into build2update(), it will be a separate diff against libtaskotron.

Test Plan

test suite passes. I also simulated this manually by commenting out koji tag download phase in task formula and instead downloading NetworkManager update manually (containing several builds). Then I removed RPMs for one of those builds. And run runtask with --setopt and set workdir to my custom location.

Diff Detail

Repository
rDEPCK task-depcheck
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
kparal retitled this revision from to better explain ABORTED checks.May 6 2015, 12:35 PM
kparal updated this object.
kparal edited the test plan for this revision. (Show Details)
kparal added reviewers: tflink, jskladan, mkrizek.

The related libtaskotron patch is in D369.

zbyszek added a subscriber: zbyszek.May 6 2015, 1:31 PM

The text looks good. I'd change "update was incomplete" to "check was incomplete" though :)

jskladan accepted this revision.May 6 2015, 2:21 PM
This revision is now accepted and ready to land.May 6 2015, 2:21 PM
tflink added a comment.May 6 2015, 4:15 PM
In D368#6635, @zbyszek wrote:

The text looks good. I'd change "update was incomplete" to "check was incomplete" though :)

The check is complete. If I'm understanding this correctly, the problem happens when the check downloads rpms, executes and when it's gathering data to report results, the builds involved with an update at that time are not the same as those downloaded prior to execution.

I don't see how we could know that the update is edited during execution and the currently planned method for handling this (mark as ABORTED, don't report to bodhi) seems appropriate to me. It'd fix itself with the next depcheck run assuming the update wasn't edited again. That should be deployed to production before final freeze.

As for the warning message - how about something like:
"Update was incomplete as downloaded at execution time and not all builds have been tested. This can happen if the update is edited in Bodhi during check execution"

kparal added a comment.May 7 2015, 9:07 AM

If I'm understanding this correctly, the problem happens when the check downloads rpms, executes and when it's gathering data to report results, the builds involved with an update at that time are not the same as those downloaded prior to execution.

Yes. However, there might be possibly other reasons why would would end up with an incompletely tested update (including some internal errors).

As for the warning message - how about something like:
"Update was incomplete as downloaded at execution time and not all builds have been tested. This can happen if the update is edited in Bodhi during check execution"

I'll go with that.

This revision was automatically updated to reflect the committed changes.