GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]

Jon Turney jon.turney@dronecode.org.uk
Sun May 9 14:40:09 GMT 2021


On 17/01/2021 15:33, Adam Dinwoodie wrote:
> On Sat, 16 Jan 2021 at 22:31, Ken Brown wrote:
>> 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

Thanks for sharing this.

One architectural problem that requires solving in cygport that we both 
have is that we aren't building from the source package, but the package 
repository (so this doesn't verify that all the files used by the build 
are put into the source package).  Ideally we'd be able to instruct 
cygport to make just the source package, then unpack and build from that.

>>> 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 caveat was mainly driven by the fact that 'it's only been tested by 
me' :)

> Yes, that was my source here. I experimented with Scallywag briefly,
> but was put off by (a) that warning and (b) the fact that my first
> builds failed because I apparently use the wrong quoting style in my
> Cygport files. And, as I say, that I was already a significant way to
> a working GitHub Action process.
> 
>> The limitations I've bumped into are:
>>
>> 1. Scallywag will time out after an hour on each arch.
> 
> This is a killer for me. Getting this working with moreutils was a
> simple proof-of-concept; the key package where this will likely save
> me time and energy is Git, and the Git test suite takes multiple hours
> to run on Cygwin. GitHub actions have a per-job limit of 6 hours, and
> a per-workflow limit of 72 hours.

Yeah.

>> 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.
> 
> That's clearly incredibly valuable, yes. I'm hoping to reduce the
> special setup using GitHub Actions requires, but it's clearly going to
> require more than zero setup.

I'd rather not be replicating the tooling to do this into every package 
repository.

All the AppVeyor builds that scallywag does are of the scallywag 
repository itself, since the AppVeyor API lets me parameterize the build 
(by the package repository and commit-id)

In a brief investigation, I didn't find anything similar for github actions.


More information about the Cygwin-apps mailing list