Hi Philip, On Fri, 18 Jun 2021, Philip Oakley wrote: > 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
