Re: [PATCH v2 00/25] CI: run "make [test]" directly, use $GITHUB_ENV

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

Hi Ævar,

On Fri, 25 Mar 2022, Ævar Arnfjörð Bjarmason wrote:

> A re-roll of my improvements my series to simplify the CI setup a lot
> (see diffstat), much of it was dealing with constraints that went away
> with Travis et al.

This type of work causes me a lot of follow-up work e.g. many merge
conflicts in the latest Git for Windows rebases.

Perhaps it is worth taking a step back and evaluating the return on this
investment in the CI setup. While this can be characterized as a
simplification taking the diffstat as proof, one could challenge that the
diffstat does not actually measure whether the code is simple or not, it
just measures whether there are less lines in the end.

If the diffstat was a good measure, then the optimum would be one 0-byte
`.c` file (which some C compilers compile without error). Another obvious
way to optimize the diffstat would be to remove all code comments. Would I
suggest to do either? Of course not.

The reduction in code size of this patch series also comes at quite a
steep cost: After all, the way Lars and Gábor set things up was already
easy to reuse with Azure Pipeline and GitHub Actions.

Removing this type of generic, easily-to-adapt code can remove a lot of
lines at the expense of making the code less generic and harder to adapt,
and leads us directly to CI lock-in.

A better approach would be to use the already-generic code and adapt it
e.g. to extend to the CirrusCI definition we have.

Even if you do not care about extending our FreeBSD coverage, I would like
to ask to slow down on refactoring as it is done in this patch series. As
indicated in my comment above, these types of refactorings lead to a lot
of complications in Git for Windows's processes, which are time-consuming
to resolve. I understand your motivation, but if you wouldn't mind taking
some time to weigh the criticality of these changes against the overhead
incurred for maintainers, it would be appreciated.

> I think just removing it is OK, we can always bring it back if needed,
> and doing so is actually going to be simpler on top of this since the CI
> is now less special, and leans more heavily on the logic of our normal
> build process.

Removing and re-adding things does take time, though. Again, I think it
would be helpful to step back and try to understand the value of this
removal versus the projected time it would take (from all involved) to
re-add.

Besides, given how much is shuffled around in this patch series (e.g. some
files in ci/ are removed altogether and their equivalent code is moved
into various other places), doubt must be cast on the idea that it would
be simple to bring back anything here.

Ciao,
Johannes