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.
