Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2020, 21:29 UTC
Message-ID: <xmqqlfm69il6.fsf@gitster.c.googlers.com>
In-Reply-To: <20200505210451.GA645290@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> On Tue, May 05, 2020 at 02:24:18PM -0400, Jeff King wrote:
>
>> But _if_ we can read from other refs in the repository, I would be very
>> happy if we parsed config out of refs/ci/branches or something. It feels
>> like that's something that ought to be possible, but I haven't quite
>> figured out a way to do it.
>
> OK, I finally figured this out. The result is the patch below, which I
> think should make everybody happy. Or at least has the ability to do so
> if they're willing to push a config ref. ;)

That sounds good.

Show 8 quoted lines

> Subject: [PATCH] ci: allow per-branch config for GitHub Actions
>
> Depending on the workflows of individual developers, it can either be
> convenient or annoying that our GitHub Actions CI jobs are run on every
> branch. As an example of annoying: if you carry many half-finished
> work-in-progress branches and rebase them frequently against master,
> you'd get tons of failure reports that aren't interesting (not to
> mention the wasted CPU).

OK.

> This commit adds a new job which checks a special ref within the
> repository for CI config, and (optionally) causes all of the other jobs
> to be skipped.

Nice---that way, all existing jobs do not even need to know about the special controlling ref.

> Right now the logic is to run CI for all branches by default, unless a
> whitelist exists, in which case the branch must be mentioned there
> (using its fully qualified ref name).

So there is no wildcard?  Not really complaining, but am wondering.

> We could easily add in a
> blacklist, as well.

OK.

> Or since we're running a shell in a VM, we really
> could just run "./allow-ref $refname" and let individual forks specify
> whatever shell code they like.

I presume that you are saying "checking out the tree of refs/ci/config and there is a program allow-ref that can tell which one to run ci on"?

> After writing that, I think we probably ought to just do the allow-ref
> thing from the start, and skip this whitelist logic. Then we should
> never need to change this workflow file again. People can implement
> whatever weird custom logic they want to.

Probably.

Show 27 quoted lines

>  jobs:
> +  check-ci:
> +      runs-on: ubuntu-latest
> +      outputs:
> +        enabled: ${{ steps.check-ref.outputs.enabled }}
> +      steps:
> +        - uses: actions/checkout@v2
> +          continue-on-error: true
> +          with:
> +            ref: refs/ci/config
> +        - id: check-ref
> +          name: check whether CI is enabled for ref
> +          run: |
> +            enabled=yes
> +            if test -e ref-whitelist &&
> +               ! grep '^${{ github.ref }}$' ref-whitelist
> +            then
> +              enabled=no
> +            fi
> +            echo "::set-output name=enabled::$enabled"
> +
>    windows-build:
> +    needs: check-ci
> +    if: needs.check-ci.outputs.enabled == 'yes'
>      runs-on: windows-latest
>      steps:
>      - uses: actions/checkout@v1

Oh, quite nice.  Simple and clean.