Re: [PATCH 0/3] Make CMake work out of the box

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 22, 2021, 22:32 UTC
Message-ID: <nycvar.QRO.7.76.6.2106221636040.57@tvgsbejvaqbjf.bet>
In-Reply-To: <bdb8bd83-c3d9-b8bd-2bd5-8b7ee0cd346a@iee.email>

Hi Philip,

On Fri, 18 Jun 2021, Philip Oakley wrote:

Show 32 quoted lines

> On 18/06/2021 14:42, Johannes Schindelin wrote:
> >>> We already exercise the plain Makefile plenty, and the CMake-based build
> >>> using Windows (in the `vs-build` job in `.github/workflows/main.yml`).
> >> There is one 'gotcha' in the yml (probably historical) in that it
> >> doesn't actually test the approach/changes that Matt addresses regarding
> >> my [1].
> >>
> >> That is, I'm looking at the 'out of the box' view, while the yml test
> >> _preloads_ the vcpkg artefacts.
> > We need to "pre-load" them because building them would add another
> > whopping 20 minutes to each CI run. And I am not talking total time, but
> > wall-clock time.
> >
> > And we're not in the business of testing vcpkg's build.
> >
> > So I am really not in favor of even thinking about changing this
> > "pre-loading" strategy.
> >
> >
> I can see the common sense in that, however I was trying to highlight
> that the approach in patch series could go stale, as did the previous
> method. Making the entry ramp to investigating the code for the wide
> variety windows users should have _some_ testing..
>
> I don't have any good ideas about how to get out of that 20 minute
> Catch-22 issue at the moment. Maybe it needs an independent, on-demand
> (i.e. infrequent;-) test.
>
> Maybe there is a way of adding a `--CI-test` option that at least
> exercises the logic without needing the vcpkg to be built again (IIRC,
> and I may well be wrong, we build once, remember the artefacts, and then
> re-used them, but .. dunno).

I would strongly discourage tacking this onto the current CI. It is way too rare a use case to merit adding the cost for all developers using the CI runs to verify their work.

All is not lost, though: interested parties (such as yourself!) can easily add their own GitHub workflows in their own repositories and verify that things work.

You could even put the workflow on a timer, and add a matrix job that builds `maint`, `master`, `next` and `seen`, to verify that things work.

And for extra brownie points, you can monitor the runs and work on fixes whenever you see breakages. That would definitely take a good chunk of the maintenance burden off of the Git maintainers.

Ciao, Dscho