Learn more about these different git repos.
Other Git URLs
It might be nice sometimes to see when a build was deleted.
Right now for example:
✗ koji buildinfo thunderbird-enigmail-2.1.3-3.fc29 BUILD: thunderbird-enigmail-2.1.3-3.fc29 [1411373] State: DELETED Built by: fschwarz Source: git+https://src.fedoraproject.org/rpms/thunderbird-enigmail.git#1b19eddd8df4482f55ce7d2642ca646005d3d223 Volume: fedora_koji_archive04 Task: 38927342 build (f29-candidate, /rpms/thunderbird-enigmail.git:1b19eddd8df4482f55ce7d2642ca646005d3d223) Finished: Mon, 11 Nov 2019 13:52:51 PST Tags: Extra: {'source': {'original_url': 'git+https://src.fedoraproject.org/rpms/thunderbird-enigmail.git#1b19eddd8df4482f55ce7d2642ca646005d3d223'}} RPMs: /mnt/koji/vol/fedora_koji_archive04/packages/thunderbird-enigmail/2.1.3/3.fc29/src/thunderbird-enigmail-2.1.3-3.fc29.src.rpm /mnt/koji/vol/fedora_koji_archive04/packages/thunderbird-enigmail/2.1.3/3.fc29/noarch/thunderbird-enigmail-2.1.3-3.fc29.noarch.rpm
✗ koji list-history --build thunderbird-enigmail-2.1.3-3.fc29 Mon Nov 11 13:52:52 2019 thunderbird-enigmail-2.1.3-3.fc29 tagged into f29-updates-candidate by fschwarz Mon Nov 11 23:35:45 2019 thunderbird-enigmail-2.1.3-3.fc29 tagged into f29-signing-pending by bodhi Mon Nov 11 23:36:10 2019 thunderbird-enigmail-2.1.3-3.fc29 untagged from f29-signing-pending by autopen Mon Nov 11 23:36:10 2019 thunderbird-enigmail-2.1.3-3.fc29 tagged into f29-updates-testing-pending by autopen Tue Nov 12 01:13:05 2019 thunderbird-enigmail-2.1.3-3.fc29 untagged from f29-updates-testing-pending by bodhi Tue Feb 4 09:04:55 2020 thunderbird-enigmail-2.1.3-3.fc29 untagged from f29-updates-candidate by oscar Tue Feb 11 11:42:06 2020 thunderbird-enigmail-2.1.3-3.fc29 tagged into trashcan by oscar Wed Mar 11 01:50:10 2020 thunderbird-enigmail-2.1.3-3.fc29 untagged from trashcan by oscar
We know it was untagged from trashcan on mar11th, which means it was probibly deleted on april 11th, but we don't know.
Might be nice to record the delete time/user/event so we could see for sure.
Also, if we have this might be nice to mention in buildinfo/on the build page...
Metadata Update from @tkopecek: - Custom field Size adjusted to None - Issue tagged with: feature
Checking the trashcan history is what I have done in the past. You're right that it's not perfect, but it is often good enough, as long at it was the gc user that did the untagging. The gc will only untag from the trashcan in two cases:
In the latter case, the most common reference to acquire at this point is another tag, which would show in the history. Builds in the trashcan shouldn't gain new buildroot refs, and shouldn't be included in new images, unless something very very strange is happening.
While this is something I would like to consider, I think it deserves a bit of thought.
I'm curious what your use cases are.
The build table is not versioned because builds are thought of as static data. However some of the fields in the table are distinctly not static:
Also, we technically have a few calls like setBuildOwner and setBuildTimestamp that alter the named fields. These are historical oddities that I wish didn't exist, but they do.
setBuildOwner
setBuildTimestamp
It might make sense to move volume and state into a separate versioned table. It would be interesting to have full history for both. This might be a bit of a complex change, though.
well, in our case when deletions were not working right for a while, it became much harder to know when a build was deleted. You can't depend on it happening on the configured time. Having that in logs would be sometimes helpfull.
Login to comment on this ticket.