Release automation revamp

[iskunk]

Ongoing discussion in #343.

This PR replaces the existing "hands-on" release automation for ungoogled-chromium's Debian package with one that is driven by Debian's own chromium package, in a fully automated process (save for rare breakage).

The core of it is the new release.yml file, which covers the entire release cycle. It checks for new chromium source packages in Debian and downloads them (get-latest.sh), converts them into corresponding ungoogled-chromium source packages (convert.sh), and uploads them to OBS for building and distribution (obs-upload.sh). If no new source packages are available, then the superfluous parts of the process are skipped.

There is also a separate script (remote-check.sh) intended to run outside of GitHub, on a home or office PC, that watches for new versions. It is much lighter weight than the GitHub workflow, and allows the release process to be triggered by a Debian package release notification sent by e-mail. (Details of how to set this up may be found in the script's comment header.)

This implementation supports multiple Debian releases simultaneously, at present bookworm (stable) and sid (unstable). It should be expandable to cover other Debian derivatives, provided that a compatible chromium source package is available as a starting point. (Ubuntu is a special case, as no such package is provided officially, but I have a conversion script that can be used to obtain one.)

The workflow requires the following vars/secrets to be defined:

Type	Name	Description
var	DEBFULLNAME	Full name of package maintainer
var	DEBEMAIL	E-mail address of package maintainer
var	OBS_PROJECT	Name of OBS project
var or secret	OSC_USERNAME	OBS account username
secret	OSC_PASSWORD	OBS account password

The dpkg-source-build.patch file is an enhancement that greatly reduces the time (and disk I/O) needed to produce the new Debian source package. It is a modification to dpkg-source(1) that I hope will be eventually merged upstream. More details may be found in the patch's comment header.

You can see a run log of this automation here, and the end products in my personal testing area on OBS.

Please let me know if any aspect of how this works is unclear. This implementation obviously covers a lot of ground, and GitHub's limitations as a CI platform did not help in keeping this simple!

[networkException]

Hi, thanks a lot for continuing the effort. My bandwidth for ungoogled work is sadly mostly limited to releases currently so I haven't had time to look at this (and the amount of bash scares me 😅).

This does look like a really nice approach though and I'll try to squeeze in testing and review in the near future

[iskunk]

Understood that time is tight. Looking forward to hearing your thoughts when you have the opportunity.

There's a lot of moving parts, to be sure! I try to aim for well-commented / self-documenting code, so if any part of it doesn't come across clearly, let me know and I'll polish it up some more.

[iskunk]

I've updated the cache expiration logic to avoid a corner case where an orig-source tarball may be deleted prematurely.

And I also added the remote-check.sh script, which I had forgotten to include in my original push :-]

[networkException]

Hi, sorry again for all the delays. Complexity is one of the major enemies for my open source time, and a bash monster is an embodiment of that :) (as well as the multiple walls of text to reach this point)

Lets move this forward, I "need" a few things:

• Do you have part of the code that you would like to have me check in depth?
• Whats required from my side after I hit merge (permissions, variables, etc.)
• Do you think you could port the OBS part to GitHub Actions in the future?

For the last one: I have some university provided build infra queued up but not configured yet. I hope to have time for that soon, but its already been a while since discussing it internally so my track record isn't great there either.

[iskunk]

Yeah, bash was the natural choice since most of the work amounted to running other programs. I take it you'd have preferred Python? :-)

Do you have part of the code that you would like to have me check in depth?

Probably remote-check.sh, since you'd be running that directly... and maybe convert.sh, since the actual conversion and repackaging happens there. The rest is either version checking, Debian downloading, OBS uploading... all the boring-but-necessary rigmarole.

If any parts of the code seem impenetrable, let me know, and I can comment it more thoroughly.

Whats required from my side after I hit merge (permissions, variables, etc.)

Need to set:

• secrets.OSC_USERNAME or vars.OSC_USERNAME (preferably the latter, since it's not exactly a secret)
• secrets.OSC_PASSWORD
• vars.OBS_PROJECT (I believe this should be home:ungoogled_chromium)
• vars.DEBFULLNAME (Full name of the maintainer that will appear in debian/changelog)
• vars.DEBEMAIL (E-mail address associated with DEBFULLNAME)

Then you'll need to generate a token for remote-check.sh to use, so it can start a workflow run.

I believe that should be everything, though of course I can't rule out a bit of back-and-forth once this goes live.

Do you think you could port the OBS part to GitHub Actions in the future?

Do you mean, build the binary packages here on GitHub?

I could probably get a build working here (with suitable hackery on the build system to get around runner limitations), but then where would those .deb files be hosted so users can install them with APT? OBS may be a PITA to deal with, but it covers both the build and distribution sides (and it can handle a Chromium build out of the box).

Plus, given that it's a semi-largish and well-known build host, it's likely to be more trusted than a private solution that few others have experience with. May I ask why you'd want to move off of OBS?