#3390 PR merged: Automate ReaR Release Builds via GH Actions

schlomo opened issue at 2025-01-29 08:49:

Here is my suggestion for automation the ReaR release builds.

Pushing a tag named like release/x.y will build a ReaR release with make ... OFFICIAL=1 after validating that the version in rear matches the release tag version.

The result is then published to our releases, where we can also manually update the release notes if we like so.

The release notes are auto generated and should - in theory - contain a list of PRs. I've seen that in my first attempt but not in the subsequent ones, and I'm happy to look at improving that in a future iteration. For now it works and in any case we can then go and paste our release notes into the GH release after it is created.

image

The download URL of the "Official source dist archive" is like this: https://github.com/rear/rear/releases/download/release/2.8.105/rear-2.8.105.tar.gz which is IMHO a fairly nice URL.

The download URL of the auto-generated source archives is unfortunately https://github.com/rear/rear/archive/refs/tags/release/2.8.105.tar.gz which is not so nice. I'm afraid that changing that would require including rear- as the prefix to the version in the release tag.

As we want to encourage people to use the official dist archive instead of the auto-generated release tag source archive I would like to suggest to simply accept that as it is. I think that people downloading such auto-generated source snapshots know what they do and it seems to be common practice to not prefix the software name to the tag, e.g. see https://github.com/fish-shell/fish-shell/tags for another example with the same behaviour.

I'll merge this this afternoon if I don't hear from you so that #3389 can proceed. Please excuse the stupid branch name, it will be gone then. I'll also squash all commits for merging to mask my bumping the version in the rear script.

schlomo commented at 2025-01-29 08:56:

BTW, I disabled CentOS 7 and SL 7 from the Docker builds, so maybe we also should remove them from the "supported" distros in our release notes

schlomo commented at 2025-01-29 14:25:

@pcahyna what do you think? Any idea why the two rpm-build jobs are failing? Is it a false positive or a real problem?

hpannenb commented at 2025-01-30 07:40:

BTW, I disabled CentOS 7 and SL 7 from the Docker builds, so maybe we also should remove them from the "supported" distros in our release notes

@schlomo: RHEL7 is still supported due to extended life cycle support (ELS) of Red Hat until June 30, 2028. Additionally SuSE provides extended support for Centos 7 until June 30, 2028 (ref. here). Maybe this should be the milestones to skip also ReaR's support of those "RHEL7"-ish OSs since they are still "alive" in the field?

schlomo commented at 2025-01-30 08:10:

@hpannenb ah, thanks for the details. Since ELS is AFAIK a paid thing I'd say that we, as the Open Source project, don't need to deal with that as part of our community efforts. In any case both RH and SUSE provide commercial ReaR support for the packages that they included. I'd hope that nobody gets to the idea to use an old RHEL7 with brand new hardware or backup software.

Personally I'm simply tired of the way how I need to update tools/run-in-docker all the time to "fix" the old RHEL7 stuff.

jsmeix commented at 2025-01-30 14:31:

@hpannenb
the fundamental difference is
what we at ReaR upstream support on a voluntary base
versus
what is supported for RHEL and SLES customers
by Red Hat and SUSE via customer support contracts.

What we at ReaR upstream describe in our release notes
is what we at ReaR upstream support on a voluntary base,
e.g. for ReaR 2.8 see
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt

In contrast
for example what SUSE supports for SUSE customers
is described in the section
"SUSE support for Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
Therein see also the section
"Relax-and-Recover (ReaR) RPM packages for disaster recovery"
what "rear..." RPM packages are provided by SUSE
for what SUSE Linux Enterprise version.

jsmeix commented at 2025-01-30 14:34:

@schlomo
feel free to drop support for older Linux distributions
when they become problematic as you like.

hpannenb commented at 2025-01-31 07:41:

Understood. At a certain time support needs to be dropped and there is obviously a difference between commercial versus voluntary support.

[Export of Github issue for rear/rear.]