Learn more about these different git repos.
Other Git URLs
The way we rsync composes today is a one-liner bash script that is not very durable and requires that a release engineer babysit it through the entire four hour rsync process.
I am going to make this more durable, however, it will also slightly change our process behind the scenes.
Today if a process works or is DOOMED after a full run it is assigned an RC release number. (EG: 1.1, 1.2, 1.3, etc). If the compose fails quickly from something such as a failure to have signed packages then it will not be assigned a release candidate.
Per @mohanboddu there is not a durable way to identify the all of the different ways the special case DOOMed composes occur so they will be assigned an RC number after the automation is deployed.
The only visible change will be extra gaps in the RC composes in /pub/alt/stage that represent these extra numbers being inserted to the sequence.
@mohanboddu is fine with this change; does anyone else have objections?
@ausil , @kevin , @puiterwijk please let me know. The initial script PR will be coming within the next two business days.
so you describe why we assign RC numbers but I don't see a proposal for a change?
What is the proposed change to our process behind the scenes?
@dustymabe from IRC:
│17:02:20 Kellin │ mboddu: mattdm issue filed, the PR will happen │ │ within next two biz days.
@dustymabe : the process currently only assigns an RC number to DOOM'd processes that got far enough to count as a compose. These are still not RSYNC'd to /pub/alt/stage.
The new process will assign ALL DOOM'd processes and RC number.
Old Way: First try: Works, RC-1.1 Second Try: Goes full run, but DOOMs at tend, RC-1.2 Third Try: Fails from lack of signing, No RC Assigned Fourth Try: WOrks, RC-1.3
New Way: First try: Works, RC-1.1 Second Try: Goes full run, but DOOMs at tend, RC-1.2 Third Try: Fails from lack of signing, RC-1.3 Fourth Try: Works, RC-1.4
Thus, under the new way, you'd have a gap that is one wider on /pub/alt/stage because instead of 1.1, 1.3 it will be 1.1, then 1.4.
This is a very minor change but @mohanboddu asked me to post an issue so everyone is aware up front that we'll suddenly have more and possibly wider gaps.
thanks for the explanation @kellin. That makes sense. I prefer it that way.
Metadata Update from @kellin: - Issue assigned to kellin
@mattdm , @ausil , @mohanboddu : the pull request associated with this issue is now filed.
https://pagure.io/pungi-fedora/pull-request/438
Metadata Update from @cverna: - Assignee reset
Login to comment on this ticket.