#2673 RFE: Consider adding deletions to build history
Opened 2 years ago by kevin. Modified a year ago

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

2 years ago

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:

  1. it is about to delete the build
  2. the build has grown references and can't be deleted.

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:

  • volume_id
  • state

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.

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.

I'm curious what your use cases are.

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.

Metadata