On Wed, Mar 08, 2017 at 10:13:14AM -0500, Kamil Paral wrote:
> > However, taskotron/resultsdb message do not include the
koji task it was
> > running
> > 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.)
I realized you didn't actually mention *scratch* builds in your message. In case
you're using standard Koji builds, then yes, that would be a problem. But I can't
imagine we would want to use standard Koji builds for this, right? That doesn't seem
right. And for scratch builds, the implementation should already exist as described above.
So if there's any reason why you wouldn't want to use scratch builds, please shout
and we can discuss. Otherwise we should be good to go here.
I did indeed no mention scratch builds as I was speaking about real builds :)
I would want to use standard koji builds for this as we will not be able to do
chain-builds in scrach builds.
Our current idea is to make creating a tag in koji much cheaper so that we can
pretty much create a new tag for each pull-request, redefine the dist-tag in
those tags and build the rpms in there to run our tests on. This way is a PR
depends on another one, we can just either use the other's package tag or use
tag inheritance or so.
Redefining the dist-tag would allow going around the nevr uniqness restriction
in koji.
Not that I'm not suggesting we change one of the existing keys in the message
but rather that we had a new one (we expect the message format rather than
redefine it).
Does this help?
Pierre