On Tue, Feb 22 2022, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Tue, 22 Feb 2022, Ævar Arnfjörð Bjarmason wrote:
>
>> It's still unclear to me how Azure CI is being used as a "fall-back",
>> can you explain that?
>
> By reinstating the `azure-pipelines.yml` file from the last known-good
> version.
Okey, despite what you might thing I'm not on the war path to remove all
of this at all costs.
In particular I don't mind much keeping the 05/25 parts around, but the
04/25 would be a hassle, depending on how you reply to the below.
So what do you expect me or someone who overtly touches code related to
this & the similar (and related) in-tree JUnit support to do? Presumably
one of:
1. Don't work on any such code at all, in case you'd one day like to
resurrect Azure support.
2. Test my patches locally by reverting azure-pipelines.yml and make
sure any overt changes to Azure-related code still work with that
reverted commit.
3. Just "YOLO hack it" but leave it in place-as is. E.g. for 04/25 and
05/25 in combination with 11/25 (the later s/export/setenv/g change)
leave a known-bad-but-looking-like-it-was-before Azure branch in-place.
4. A variant of #2 where I attempt to patch the Azure code branches, but
the "testing" is just eyeballing that they look reasonable, but I haven't
*really* tested them even once (and I'd note as much in a commit message).
I'm not willing to go for #1 and #2. I could do #3 or #4 if Junio/others
chime and agree with you, but I really don't think those are worth it
either.
I could understand your view in your reply back in December when I sent
the stand-alone Azure removal patch[1]. Even though I noted that it was
needed for subsequent changes it was a stand-alone patch, so it wasn't
easy to evaluate the trade-off of whether removing it was worth it.
I think here it is quite easy. The end-state of this series
significantly improves the UX for the CI we actually use, and I think
actually makes it easier to get Azure support back up & running should
you ever want that, since the whole structure of it is making CI less
complex and less of a special-case.
It's been almost 2 years (just around 2 months short of it..) since
azure-pipelines.yml was removed from "master". It would really be quite
easy to get it or any other new CI target off the ground, particularly
after this series.
Insisting that any effort to fix actual CI issues in the actual CI we do
use needs to be hamstrung by any change in the area needing to carefully
eyeball:
git show 6081d3898fe^:azure-pipelines.yml
And for each change carefully consider them *if* we still ran that just
seems unreasonably obstructionist.
Sure, Azure CI had some neat features, so did Travis CI. If we ever want
to run either of them again let's just consider that if and when that
happens.
Maybe you have relevant feedback queued up, but so far you haven't had
any meaningful comments on the goals end end-state of this series as
compared to yours[2] (to the extent that their approaches differ).
Can we try to focus on that instead? I.e. the actual visible CI changes
that'll either make the CI workflow we actually use better or worse?
1. https://lore.kernel.org/git/patch-1.1-eec0a8c3164-20211217T000418Z-avarab@xxxxxxxxx/
2. https://lore.kernel.org/git/pull.1117.git.1643050574.gitgitgadget@xxxxxxxxx/
