SOP: how to build a hotfix #4056
Conversation
|
Please comment about the last section. |
Pull Request validationFailed🔴 Review - Missing review from a member (2 required) Success🟢 CI - All checks have passed |
|
|
||
| Create hotfix branch ($DATE is date of last release): | ||
|
|
||
| git branch hotfix-$DATE |
There was a problem hiding this comment.
Please also git checkout ..., otherwise we git reset the main branch later.
There was a problem hiding this comment.
do you mean by this rebasing on the upstream/main before creating the hotfix branch, right?
|
|
||
| optionally you can change even: | ||
|
|
||
| builder = tito.builder.UpstreamBuilder |
There was a problem hiding this comment.
Not sure if I should commit those changes?
There was a problem hiding this comment.
If so, can you please add the command with already prepared commit message, so that we can easily copy-paste it from the docs?
|
|
||
| git branch hotfix-$DATE | ||
|
|
||
| Return in history to commit that points to latest commit tagging packages for the release: |
There was a problem hiding this comment.
This might be a bit hard choice, not sure, we'll see in practice. Consider history like (last commit goes first)
- aaa: to-be-hotfixed commit to python-copr
- bbb: irrelevant commit for copr-backend
- ccc: [python-copr] tagged
- ddd: to-be-hotfixed commit to copr-backend
- eee: [copr-backend] taged
- fff: [copr-frontend] tagged
- 000: other commit covered by subsequent tags
Now, I want a hot-fix branch, and have a hot-fix for both [python-copr] and [copr-backend]. Where do I start?
There was a problem hiding this comment.
can't we just cherry pick the relevant commits instead?
| and walk the directories of packages listed. For every SPEC file make sure that `Version` tag has `^hotfix` at the end. | ||
| This ensure that the hotfix version is higher than any rebuild in Fedora. | ||
|
|
||
| 1.1-5 < 1.1^hotfix-1 |
|
|
||
| or | ||
|
|
||
| Create hotfix project in Copr itself. Enable this repo in production. Build there the hotfix and install from Copr. |
There was a problem hiding this comment.
At this point in time, we have those files most likely patched in production, vim-modified, I know -- 🥇.
Anyway, that's the most convenient thing to do and I doubt it makes any sense to change our practice; IOW we are not in hurry, we can simply wait till the package gets to infra tags -- and then do a no-brainer dnf update.
There was a problem hiding this comment.
Anyway, that's the most convenient thing to do and I doubt it makes any sense to change our practice;
meaning of this is not creating this SOP? or is it encouragement to follow the https://docs.pagure.org/copr.copr/how_to_release_copr.html#build-packages-for-production ?
tbh I am against both, current status is definitely not ideal, yep. And having it released to fedora bring no benefits in my view... only adding boring process at the end of creating of the hotfix... is there really some big difference for us to have the hotfix directly to fedora that makes it no-brainer? Is there some benefit I am missing?
There was a problem hiding this comment.
I meant that even with this (a go-to, really) SOP, you can still edit with vim, but then you must provide a hot-fix package and simply run dnf update to apply it (in an hour or so..).
|
Thank you very much for the document, @xsuchy 🚀 |
| @@ -0,0 +1,75 @@ | |||
| .. _how_to_build_hotfix: | |||
There was a problem hiding this comment.
We should probably link this from the maintenance_documentation.rst
|
we could test this on #4092 after new year to unblock packit/packit-service#2907 :) |
| Edit `tito.props` to: | ||
|
|
||
| tagger = tito.tagger.ReleaseTagger | ||
|
|
||
| optionally you can change even: | ||
|
|
||
| builder = tito.builder.UpstreamBuilder |
There was a problem hiding this comment.
I'd love to (just personal wish) have here short description (a few words) about what is the use case when I should include also the second (builder) option
4 participants
No description provided.