I have been working on a small tool named protron  that listens to pagure
pull-request messages, triggers a build and report build status as well as
taskotron/resultsdb test results to the pull-request.
Hi pingou, you forgot to include the  link, but it was easy enough to find :-)
Great choice of a name! :)
Since protron kicks off the koji build, it knows its task identifier and
it in memory so that it can later recognize a koji build it kicked versus a
build from something/someone else.
However, taskotron/resultsdb message do not include the koji task it was
the tests against.
The code to process Koji scratch builds is very experimental and I don't know if
it's already deployed somewhere, but the published result should definitely include
Koji task ID. It should be even reported as the "item" (and the type of the
result is "koji_task"). Can you link to results which fail to do that? I can
look for bugs. (Provided we even reported such results already, again, I'm not sure.)
So protron queries koji taskinfo <id> to get the package
nevr this task was about and keep then that info in memory to recognize
taskotron messages of interest.
In our regular workflow this isn't a problem because of the nevra restriction
koji is such that we cannot build the same package twice, but with the PR
coming to dist-git, we will need to somehow lift that constraint. There could
very well be two persons or two systems proposing a pull-requests doing the
update (say the-new-hotness bumps foo to 1.2.3 while missing something, while
contributor comes by and do the same update to 1.2.3 with the rebase of the
patch or so), both PRs will be building foo-1.2.3 and this will confuse
to which PR corresponds foo-1.2.3?
Yes, we're aware that Koji scrach builds don't need to have unique NVRs, and
that's why we need to handle it differently from standard Koji builds. Our goal is to
reference them by task ID (because there seems to be no better identifier specific to koji
scratch builds, it's just a generic task).
If the PR are created with sufficient time in between, this will not be a
problem, the newer PR will override the info in memory of the old one.
However, if the two PRs are created sufficiently close to one another (so
the tests for the first PR aren't finished running), this will be an issue.
To avoid this, one way would be to add to the taskotron message sent the task
of the build taskotron was testing.
Would this be something that is doable?
It should work out of the box once this is deployed :) If you see issues with some
experimental deployment, let us know.
It might be better to use qa-devel for these kind of discussions, I'm not sure if
everyone is subscribed here. IIUC this list is more about resultsdb conventions and stuff.
(Adam, your list hijacks our qa-devel conversations!:))