Re: [PATCH] CI: remove support for Azure CI

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Dec 20 2021, Johannes Schindelin wrote:

> Hi Ævar,
>
> On Fri, 17 Dec 2021, Ævar Arnfjörð Bjarmason wrote:
>
>> Remove various code required to support Azure CI. Recently in
>> 4a6e4b96026 (CI: remove Travis CI support, 2021-11-23) we removed the
>> Travis CI support, which was last used in June 2021.
>>
>> The supporting infrastructure for Azure CI was already partially
>> removed in 6081d3898fe (ci: retire the Azure Pipelines definition,
>> 2020-04-11). As that commit notes:
>>
>>     We have GitHub Actions now. Running the same builds and tests in Azure
>>     Pipelines would be redundant, and a waste of energy.
>>
>> This follow-up removes the relevant Azure Pipelines-only supporting
>> code. Most of it was added in commits merged as part of
>> 57cbc53d3e0 (Merge branch 'js/vsts-ci', 2019-02-06).
>
> It feels premature to remove the remnants of Azure Pipelines support
> already now. It would be better to hold off a little, as much fun as
> deleting and refactoring code may be for some of us.
>
> The reason is that there are still some things that Azure Pipelines can do
> that GitHub workflows cannot, for example:
>
> - present the logs of failed tests in an intuitive manner,
>
> - re-run _only_ failed jobs.
>
> At this stage, I am not convinced yet that we should bet completely on
> GitHub workflows.

I think these concerns should be addressed by the rest of the commit
message that follows the paragraph you quoted.

I.e. I'm not deleting this for fun, but because certain improvements to
test-lib.sh require patching the JUnit emitter.

Since there is no current user of it or a way to test it against a
working CI mode such changes are harder to make and to review.

Those changes being things I've got locally that achieve some of the
same aims you note here. I.e. getting guaranteed machine-parsability of
the test-lib.sh TAP output, to e.g. present failing tests intuitively.

My 707d2f2fe86 (CI: use "$runs_on_pool", not "$jobname" to select
packages & config, 2021-11-23) also shows that by removing these dead or
unused modes it becomes easier to make the CI less GitHub-dependant.

I'd like to follow-up with that and e.g. make the "install *.deb
packages" step of CI be something you can trivially invoke via a
corresponding "make" target, and generally make the commands and checks
we run in CI a much thinner wrapper for targets you can easily run
locally without mocking up a bunch of fake values for ci/lib.sh
first. The changes in ci/* here are a small step towards that,
i.e. fewer (and in this case, not easily testable) special-cases we need
to worry about.