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