Discrepancy with the tag and then the release of 4.6.1

[arif-ali]

Was just testing some testing in the 4.6.1 tag, and found a discrepancy with the tag, and then the commit for the version

commit d338a232cd7c829ca8ca5e5febef51035d1f7da5
Author: Pavel Moravec <pmoravec@redhat.com>
Date:   Wed Jan 10 16:47:44 2024 +0100

    [build] Bump version to 4.6.1
    
    Signed-off-by: Pavel Moravec <pmoravec@redhat.com>

commit d43b1e0651f179f11213e4aa57bcae457d6dc664 (tag: 4.6.1)
Author: Pavel Moravec <pmoravec@redhat.com>
Date:   Mon Jan 8 09:01:47 2024 +0100

    [collect] Imply --upload when --upload-url is set
    
    Setting --upload-url should imply uploading the tarball at the end,
    regardless of --upload is explicitly set or not.
    
    The same is already in place for "sos report", so let unify it.
    
    Resolves: #3464
    
    Signed-off-by: Pavel Moravec <pmoravec@redhat.com>

So, at he moment, if the tarball from 4.6.1 release is downloaded, then the version will still be shown as 4.6.0 when running sos

[pmoravec]

Indeed, that is my fault, I apologize for it. I have forgotten bumping the versions before I did the tagging, so I bumped the versions in the next commit. I could changed git history but.. that wouldn't be nice either.

I will recall this the next time when I will do the "z-stream tagging". Until this can be automated, somehow..?

[arif-ali]

Thanks @pmoravec, was doing some release testing in prep for further testing when 4.7.0 comes out, so that we're ready

When we do the debian release, it downloads the tagged tarball from GH as a source of truth.

also a heads up (for next time), the same seems to have happened with the tagging, as I see the snap was tagged with version sos-4.6.1 and not 4.6.1 as shown below

channels:
  latest/stable:        4.6.0-1            2023-09-29 (242) 12MB classic
  latest/candidate:     sos-4.6.1          2024-01-10 (298) 13MB classic
  latest/beta:          ↑                                        
  latest/edge:          4.6.1-21-gab5f7cec 2024-01-23 (314) 24MB classic

Maybe worth writing the release process down in the wiki, so that we can all be consistent in the release process?

[pmoravec]

I am definitely in favour of having it written. I shall start writing it down as a kind of pay back for the mistake, and ask at least @TurboTurtle (as the most experienced one :) ) for a review and completion of forgotten gaps. I hope I will have time for this over the weekend.

[pmoravec]

But how the sos-4.6.1 tag appeared? There is no https://github.com/sosreport/sos/releases/tag/sos-4.6.1 but there is https://github.com/sosreport/sos/releases/tag/4.6.1 likewise previous https://github.com/sosreport/sos/releases/tag/4.6.0 . (I am just trying to figure out how to prevent this / what step to set/change to have proper tag in snap channels)

[arif-ali]

Yeah, not sure what happened, here's the logs from the workflow, and git describe at the time showed sos-4.6.1 https://github.com/sosreport/sos/actions/runs/7471795632/job/20332699422#step:3:43, hence why the snap delivered sos-4.6.1.

Agreed, that I don't see that tag anywhere, so not sure where that came from 🤷🏽‍♂️

[pmoravec]

I created https://github.com/sosreport/sos/wiki/Maintainers-checklist-for-releasing-a-new-version-or-tag . Now it should have all steps (I am aware of).

[arif-ali]

On the deb side, if you have devscripts installed, then you should be able to run the following command

DEBEMAIL="${gituser}" dch -v ${newvers} --distribution mantic "New upstream release" 

mantic above is the codename of the latest release that is being supported. This can easily identified with looking through the .cirrus.yaml https://github.com/sosreport/sos/blob/main/.cirrus.yml#L31, this will show the release that the deb package is being built against for testing.

The above command/package may not be available on rpm based distros, so below alternative may be easier. Again replacing mantic with the release as shown by cirrus above.

debdate=$(TZ=UTC date "+%a, %d %b %Y %H:%M:%S +0000")

ed -s debian/changelog << EOF
0 i
sosreport (${newvers}) mantic; urgency=medium

  * New upstream release

 -- ${gituser} ${debdate}

.
w
EOF

[pmoravec]

I added the step to the Wiki - also with parsing the codename of the latest supported release from .cirrus.yml.

[arif-ali]

Just circling back on this, it seems like the process has worked, my only thing is that the changelog for debian/changelog has 2 entries for 4.7.1 instead of 1

[pmoravec]

Ah, I apologize for that. The commands on wiki should be good, they add one such entry. I think the error happened because I added the change once semi-manually, and for the 2nd time when I was testing the commands for wiki..

Feel free to git push a change to remove the duplicate entry, if that matters. And it would be worth reviewing this once/when I will do 4.7.2 (in 1-2 week manner).

[arif-ali]

That's OK on my behalf, we don't use this version in the downstream, so doesnt really matter. Was more of a curious one :).

Hopefully the next one goes to plan, and we can close this discussion off

[TrevorBenson]

I'm not familiar with the current process/workflow for how SOS handles this other than reading the Maintainers checklist today. At first pass it seems like this might be beneficial to create a dedicated workflow that would do the described steps automatically and ensure that both the tag and the bump occur together, reducing the chance of error, copy/paste failure etc.

I found a GitHub Action that is intended to perform a tag + bump, although I'm not a fan of automating it entirely based on commit messages as it suggests. With or without this Action it could probably still be made into a workflow leveraging workflow dispatch and inputs, allowing explicitly setting newvers in the input, and letting it handle everything else.

I enjoy doing a bit of CI now and again, so if this is something of interest I could work up an example branch in my fork and attempt some basic tests to validate.

[arif-ali]

As this has been taken care of, and we've had several releases since, I'll close this off