On Fri, Aug 14, 2020 at 02:08:28PM +0200, Johannes Schindelin wrote:
> On Wed, 12 Aug 2020, Jeff King wrote:
>
> > From my perspective as somebody who does not work on Windows, I wonder
> > how much value there is in running vsbuild _and_ Windows CI for average
> > developers. I have certainly gotten information from these jobs (e.g.,
> > when introducing a portability problem, or missing a refactoring spot in
> > Windows-only code). But I don't think I've ever gotten information from
> > vsbuild that wasn't also in the regular windows build.
>
> There have not been a _ton_ of these instances, but there have been a
> couple:
Thanks, that was exactly the kind of data I was interested in.
> I cannot find any more instances, so yes, I agree that the
> `vs-build`/`vs-test` jobs might not be _all_ that necessary. So maybe we
> should do something like this?
Let's leave it be for now. The topics I had to adjust due to cmake were
ones that I'd had sitting around for a while. So while I hit problems
immediately, now that the queue is drained it's not clear to me how
often it will come up in practice.
> -- snipsnap --
> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> index 30425404eb3..2549fff8edd 100644
> --- a/.github/workflows/main.yml
> +++ b/.github/workflows/main.yml
> @@ -122,7 +122,7 @@ jobs:
> path: ${{env.FAILED_TEST_ARTIFACTS}}
> vs-build:
> needs: ci-config
> - if: needs.ci-config.outputs.enabled == 'yes'
> + if: (github.repository == 'git/git' || github.repository == 'gitgitgadget/git') && needs.ci-config.outputs.enabled == 'yes'
If we do go this route, I'd consider defaulting it to on and just
letting people disable it through needs.ci-config.outputs.vsbuild or
similar.
-Peff
