Learn more about these different git repos.
Other Git URLs
One of the reason for this request is https://bugzilla.redhat.com/show_bug.cgi?id=1623547 where I'm almost sure I had a F-29 nightly compose behaving sanely on s390x in the past, but have nothing I could compare with the current state.
When do you need this? (YYYY/MM/DD) soon
When is this no longer needed or useful? (YYYY/MM/DD) never
If we cannot complete your request, what is the impact? Difficult to find out what changed (functionally) in the composes as the previous compose is the GA compose of the last release. AFAIK it's almost impossible to recreate an old compose from a given date on demand.
I was thinking of koji inheritance, so that it wont occupy any space and we can go back to what ever date we want to and create a compose out of it.
This doesn't mean that we will have the compose ready, whenever someone wants to have a compose from a certain date, we can re-create it.
Metadata Update from @mohanboddu: - Issue tagged with: meeting
I think simply adding a "nightly" tag (like f29-20180904.n.0) might work, following a policy suggested above. AFAIK pungi returns event id for the state of the tag it run on, then we would add a tag to all builds matching this event. At the end one could ask "please, re-create a $arch / $variant compose from $nightly_tag".
maybe koji clone-tag --event <pungi_event> is what we need
koji clone-tag --event <pungi_event>
The event is available in work/global/koji-event in each compose. It's a JSON file with id and timestamp.
work/global/koji-event
Metadata Update from @syeghiay: - Issue assigned to mohanboddu
From RelEng meeting on May 29 2019:
#info We will not change the policy but we will keep track of the koji event id (probably in fpdc) from which we can clone a koji tag and run a compose from it if and when its really needed.
Metadata Update from @mohanboddu: - Issue close_status updated to: It's all good - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.