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

From: Jeff King <peff@peff.net>
Date: May 7, 2020, 14:02 UTC
Message-ID: <20200507140208.GA3060463@coredump.intra.peff.net>
In-Reply-To: <20200507121727.GA3057274@coredump.intra.peff.net>

On Thu, May 07, 2020 at 08:17:27AM -0400, Jeff King wrote:

Show 10 quoted lines

> > But doesn't this (i.e. uses: actions/github-script) still pay the
> > cost of spinning up a VM?  How expensive is it to check out a small
> > tree with a single file, whether it is ref-whitelist or allow-ref?
> 
> I suspect this script mechanism may be much cheaper. I don't know the
> implementation details, but spinning up a nodejs container to run a
> javascript snippet should be much cheaper than a full ubuntu VM running
> "git clone" (the clone itself should be super cheap because it's a
> shallow single-branch clone of a tree with one file in it, but getting
> there is relatively heavy-weight).

Sorry, this is all complete nonsense. There is no magical nodejs container in Actions. You still have to say "runs-on: ubuntu-latest". So it's still spinning up that VM and then running inside there.

I just did a timing with three jobs:

  noop:
    runs-on: ubuntu-latest
    steps:
    - run: exit 0

  script:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/github-script@0.9.0
      with:
        script: |
            const req = {
              owner: context.repo.owner,
              repo: context.repo.repo,
              ref: "refs/ci/config"
            };

            try {
              req.tree_sha = (await github.git.getRef(req)).data.object.sha;
              (await github.git.getTree(req))
              .tree.filter(e => e.path == 'ref-whitelist').map(e => {
                req.file_sha = e.sha;
              });
              const list = Buffer.from((await github.git.getBlob(req)).data.content, 'base64').toString('UTF-8');
              core.setOutput('enabled', `\n${list}`.indexOf(`\n${{github.ref}}\n`) < 0 ? 'no' : 'yes');
            } catch (e) {
              core.setOutput('enabled', 'yes');
            }

  checkout:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      continue-on-error: true
      with:
        ref: refs/ci/config
    - run: ./allow-ref ${{ github.ref }}

and they took 1, 2, and 3 seconds respectively. They spend 2s getting the environment set up and the actions loaded. So the API one spent less than 1s on the network, but the single-file checkout spent slightly more. Given the timing variations I've seen, I wouldn't be surprised if it sometimes goes the other way. But even if those numbers are accurate, I don't think the cost difference is enough to force our hand either way.

-Peff