On Mon, 9 Jan 2017 08:09:52 -0500 (EST) Martin Krizek <mkri...@redhat.com> wrote:
> Hi team,
>
> we have received a few requests to run tasks on koji scratch builds.
> Unfortunately, it is not as straightforward as it would seem since
> "real" koji builds and scratch builds are not treated the same.
> That's why "real" builds are downloaded with "koji download-build"
> and scratch builds are downloaded with its own tool called
> "koji-download-scratch" which is part of the fedora-review package.
>
> The way the "real" koji builds work is that they are referenced by
> NVRs since NVRs are unique (I think there can be multiple builds with
> the same NVR, many with "failed" status and just one with the
> "completed" status and only the completed ones are searched, but
> that's just my guess). In taskotron's koji tasks, we feed NVR's to
> libtaskotron's koji directive which downloads build's RPMs.
>
> In the case of scratch builds, they are not referenced by NVR's but
> rather just with task ID's.
>
> With that being said, we just can't write a trigger for listening for
> the scratch builds fedmsgs [1] and trigger a libtaskotron job because
> there's no NVR in the fedmsg and even if it was, we wouldn't be able
> to download the rpms.
Couldn't we use the task ID as the primary identifier but use the srpm
for readability sake since there is no "build" NVR for scratch builds?
Either that or make the primary ID a tuple of (srpm name, koji task
start time) either stored that way or rendered as a string e.g
foo-1.2-3.fc99.src.rpm built at 201701092100 (YYYYMMDDHHMM) would become
foo-1.2-3.fc99-201701092100.
> During a discussion with Kamil, a few solutions were mentioned (none
> of them is pretty):
>
> 1. We can ask koji developers if there is a way to add a method that
> would return all koji scratch builds for a given NVR - we would then
> take the latest one and work with it.
How would we get the NVR if there's no build identifier on scratch
builds? Are you talking about the SRPM name in the fedmsg?
> 2. We can use "koji download-task" which works for both. That would
> mean koji_build item type would eat koji task IDs instead of NVRs.
> This would lead to having koji task IDs in resultsdb instead of NVR's
> which kills readability. Unless libtaskotron finds the NVR from the
> koji task ID in the case of "real" build" and stores it in a field in
> resultsdb...Also, we need NVRs for fedmsgs. So add code to the fedmsg
> layer that would take care of somehow adding a NVR to fedmsg of
> completed scratch builds tasks...
Can't we tell the difference between an NVR and a task ID just by the
form that the content takes? Wouldn't the following work:
1. attempt to parse input as NVR, if there are no issues, assume that
it's a build ID
2. if the NVR parse fails, check to see if the input is an int. if
assume that it's a koji task ID
It'd mean that our koji downloading code would get more complicated but
it seems like nothing that more unit tests couldn't mitigate. Unless
I'm mis-thinking here, the changes needed to pull this off in trigger
would be even smaller.
> 3. We can add a new action to the koji directive "download_task". And
> then have for each koji task two formulas, one for scratch build
> (using "download_task") and one for "real" build" (using
> "download_build). This would require writing code for supporting
> multiple formulas for one task and would result in having two almost
> identical formulas...
I'm not a huge fan of 3 if there is any other reasonable way to do
things. Code duplication is not the way to go.
> Before proceeding with 1. and asking koji folks if they are able to
> help with that I wanted to check here if anyone has any thoughts on
> this.
If what I wrote above would work well enough, that sounds like a good
way to go forward to me. If not, 2 sounds like a decent option.
Tim
pgpyhqQB81L01.pgp
Description: OpenPGP digital signature
_______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
