[releng] Issue #7568: Tag fedora-kickstarts (and fedora-comps?) repo for candidate composes

[Adam Williamson]

adamwill reported a new issue against the project: `releng` that you are following:
``
So, I recently floated a proposal to remove the release criterion that requires a
spin-kickstarts package that corresponds to the kickstarts used to create the release be
included in the release. This has met with a generally positive response, but before I go
ahead with it, I think we should ensure the proposed replacement is done already.

That idea is, every time a candidate compose is done, a tag should be created in the
fedora-kickstarts repo with the compose's ID (and/or label). That way it's easy to
get the correct kickstarts that match the compose: just check out the tag.

We could also do this for *nightly* composes, I guess, it just depends whether creating
tons of tags causes any problems for git - I don't know if it does or not.

We could also tag the fedora-comps repo, possibly; it's less important in that case as
the actual generated comps automatically become a part of the compose itself, but could
still be useful.

Ideally this should be a part of the scripts that produce the compose, it should not be a
manual step that the person doing the compose has to remember to do, as of course that
introduces the possibility that they won't.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7568

[Dusty Mabe]

dustymabe added a new comment to an issue you are following:
``

>  That idea is, every time a candidate compose is done, a tag should be
> created in the fedora-kickstarts repo with the compose's ID (and/or label). 
>  
seems a bit overkill. we could just make the criteria be that a tag is created in the repo
that matches the gold compose we release. my preference here is that we only tag when we
do a major release so that we don't have a million tags. 

>  That way it's easy to get the correct kickstarts that match the
> compose: 
>  
That information is in the logs of the compose right? 
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7568

[Adam Williamson]

adamwill added a new comment to an issue you are following:
``
Well, I just figured doing a tag for each candidate compose is the *easiest* way to ensure
we have a tag for each release. I don't see a way to do it only for the compose we
actually release other than manually. But if you'd prefer to do it that way I'm
fine with it, so long as we're solidly on top of actually doing the tag.

I wasn't planning to have a release criterion at all - if the process was automated it
shouldn't really be necessary - but if we want to go with a manual process then that
would make sense as a way to help ensure it gets done, I guess. I was kinda hoping to
avoid that whole 'manual checking' thing, though.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7568

[Mohan Boddu]

mohanboddu added a new comment to an issue you are following:
``
I prefer one tag per release slightly better than tagging every release candidate, such
that we can find what we shipped in the release instead of finding the release compose
version number and matching that against the multiple tags that we *might* create for
different release candidates.

>  
We could also do this for nightly composes, I guess, it just depends whether
creating tons of tags causes any problems for git - I don't know if it does or not.

Seems like a over kill for me.

>  
We could also tag the fedora-comps repo, possibly; 

I dont know what we can achieve from it also the repo is just one master branch with all
the release comps in it. We can still tag it, but that seems odd as it also has other
release information.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7568

[Dusty Mabe]

dustymabe added a new comment to an issue you are following:
``
>  I was kinda hoping to avoid that whole 'manual checking'
> thing, though.
>  
+1, once every 6 months isn't too bad. and the way we've changed it (to not
require an rpm but just make sure a tag is created) means it's not something where
ordering and timing matter as much. I'm just trying to avoid us having to architect a
process that does and blocking something else.

Either way works for me, just throwing out options. 
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7568

[Adam Williamson]

adamwill added a new comment to an issue you are following:
``
Making sure a tag has been created is certainly a lot less effort than getting a package
built and included in the final compose, no argument there. It'd still be an
improvement.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7568

[Adam Williamson]

adamwill added a new comment to an issue you are following:
``
I've sent out a proposal to replace the existing criterion with one requiring a repo
tag to be done for Final.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7568

[Adam Williamson]

The status of the issue: `Tag fedora-kickstarts (and fedora-comps?) repo for candidate
composes` of project: `releng` has been updated to: Closed as Fixed by adamwill.

https://pagure.io/releng/issue/7568

[Adam Williamson]

adamwill added a new comment to an issue you are following:
``
We wound up implementing that proposal, so this is done now, I guess.
``

To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7568