Hi Junio, On Tue, 13 Jul 2021, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > .github/workflows/run-sparse.yml | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > create mode 100644 .github/workflows/run-sparse.yml > > We choose to do this as a separate new workflow not as part of the > main one because this is more like check-whitespace where there is > no room for tests over the matrix of compilers and platforms play > any useful role? Ubuntu's `sparse` package was historically not up to date, not enough at least to support Git's `make sparse`. Hence I created an Azure Pipeline to build an up to date package, and since v1 used the GitHub Action `get-azure-pipelines-artifact`. As a consequence, I thought, that this was inappropriate for `main.yml` because we still try to _somewhat_ keep that in sync with `.travis.yml`. However, I realized that there are already too many differences (all the Windows builds for example, which our Travis CI definition did not follow suite, even after Travis CI got support for Windows agents). So I folded it into the regular GitHub workflow. There is one really big downside to that, though: currently, there is no way to re-run only failed jobs in GitHub workflows (this is in contrast to Azure Pipelines). You can only re-run _all_ jobs. Which means that the likelihood of a run to fail increases with the number of jobs in said run (even innocuous problems such as transient failures to download an Ubuntu package), and it also makes it much more painful to re-run the entire thing because you may well end up wasting a grand total of ~370 minutes even if only a 30-second-job would need to be re-run. Having said that, I think you're right and the upside of keeping things together may outweigh that downside. Ciao, Dscho
