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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 06, 2020 at 09:26:53AM -0700, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> > The idea is indeed very neat. I think we can do a bit better with resource
> > usage by not even bothering to check this branch out. Something along
> > those lines (sorry, I really would love to have the time to test this...):
> 
> Nice.  I view the latest round of Peff's idea "allow-ref" as
> "because we are spinning a VM anyway, why not just run an end-user
> supplied script and let it decide?" and not as "we must have a
> Turing complete flexibility so let's run a script in a VM".  In
> other words, it may be overkill and we may strike a better tradeoff
> by living with reduced flexibility if there is a way to avoid the
> associated cost.

The script is just javascript, which has an eval(). We could probably
let refs/ci/config:allow-ref be a snippet of javascript that we run.

I do prefer the VM environment to snippets of javascript for a few
reasons:

  - shell scripts match the rest of our Git toolbox (though that's a
    personal preference, and for the amount of code we're talking about
    even _I_ can do a little javascript)

  - it's easy to test your code locally by running "./allow-ref foo".
    Whereas emulating the environment in which those scriptlets are run
    is much trickier (e.g., you need a working github-api object)

That said, if this is more lightweight, I think it's worth exploring.

> 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).

But I could be wrong.  It's clear that they're not spinning up a full
ubuntu vm from scratch to serve the requests (since it happens in 3s).
I'll see if I can get something working and do some timings.

The latency isn't incredibly important. This is all happening async, and
either we'll skip CI (in which case you don't care how long it takes,
since you're not waiting on the result) or CI will take many minutes, in
which case 3s is nothing. But I would like to be respectful of the CPU
spent running Actions and be as lightweight as possible.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux