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.
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?
If the cost to check out a tree is dwarfed, it probably is not worth
pursuing the approach to use a canned "don't customize, just use"
logic in the workflow file to read a configuration file that can
only list full names of allowed refs.
Thanks.
> - id: check-ref
> name: check whether CI is enabled for ref
> uses: actions/github-script@0.9.0
> with:
> script: |
> const req = {
> owner: context.repo.owner,
> repo: context.repo.repo,
> ref: "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');
> }
>
> Ciao,
> Dscho
