GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]
Ken Brown
kbrown@cornell.edu
Sat Jan 16 22:31:06 GMT 2021
On 1/16/2021 3:33 PM, Adam Dinwoodie wrote:
> On Sat, 16 Jan 2021 at 20:22, Adam Dinwoodie wrote:
>> Version 0.65-1 of moreutils has been uploaded and should be coming
>> soon to a distribution server near you.
>
> In case anyone's interested or has thoughts:
>
> As part of working on this release, I've been playing with GitHub's
> automation tools. The entire build / test / package / release / upload
> process was performed using free ephemeral GitHub-managed VMs. At
> least in theory, this reduces the manual work for future releases to:
>
> - Commit a version of the Cygport file with an updated version number.
> - Create a tag and push that tag to GitHub
> - Wait for the confirmation email to arrive
> - Send the announcement email
>
> This is obviously serving a similar purpose to the automated builds
> that Scallywag provides; I'm not sure I'd have bothered with this
> project had I not already been most of the way through it before I
> spotted Scallywag existed. I suspect in theory Scallywag's access to
> the Cygwin servers means it's potentially more powerful, but Scallywag
> also comes with some general caveats ("at this stage, this is only
> probably useful for verifying that BUILD_REQUIRES is correct"),
I assume you're quoting from https://cygwin.com/packaging/build.html. Scallywag
does have some limitations currently, but I think the statement you quoted is
obsolete. I often have Scallywag deploy my packages, as does Jon Turney.
The limitations I've bumped into are:
1. Scallywag will time out after an hour on each arch.
2. Several of my packages fail to build on x86 because of gcc crashes.
I think these limitations are outweighed by the fact that a Scallywag build is
automatically triggered by a push to an official source repo
(https://cygwin.com/packaging/repos.html). All maintainers can use this without
any special setup.
Ken
More information about the Cygwin-apps
mailing list