> 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 :)
Ok, so none of what I said applies.
I would want to use standard koji builds for this as we will not be able to
do
chain-builds in scrach builds.
Aaand, would that be hard to implement? Because I believe it would be waaaay more easier
for us to do this with scratch 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).
The problem is that the tasks themselves are in control of creating the result message.
The only thing we can count on to be included is testcase and item and outcome. We can of
course modify all tasks we own to make a query at the end, figure out Koji task ID (or
perhaps receive it from the trigger right away), and include it in the result as an
additional field. But you can't rely on that. Any third-party koji_build task (however
useful it is) might not include the same information.
So I see two options here:
a) Make the NVR very unlikely to collide. For example use a timestamp (down to a
millisecond) in the Release field.
b) Rely on tasks providing "task-id" field in results. If there's no such
field, ignore the task.
The first one seems better. The second one wouldn't be that bad for generic tasks (in
the long run, we will probably not want to run "all available koji_build tasks"
anyway, just set a selected set of those we consider useful), but it would be hostile
again package-specific tasks in dist-git (every single task of every single package would
need to do the right thing). We definitely want to create a better experience for dist-git
tasks in the future (shield you from all the implementation stuff and automatically do
everything needed for you), but we're not there yet.
So those are the short-term solution I can see. Long-term, maybe we could re-think how we
create results and perhaps separate taskotron-provided results field from task-provided
results field, and therefore ensure information like task-id is always present. But
that's definitely not something we can do quickly.