Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches
- From
Đoàn Trần Công Danh <congdanhqx@gmail.com>
- Date
- May 7, 2020, 12:47 UTC
- Message-ID
- <20200507124700.GA1378@danh.dev>
- In-Reply-To
- <20200507120102.GB32465@danh.dev>
On 2020-05-07 19:01:02+0700, Đoàn Trần Công Danh <congdanhqx@gmail.com> wrote:
Show 11 quoted lines
> On 2020-05-06 17:09:39+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > 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...): > > While this can avoid the cost of checking out a whole branch (which > can be mitigated by using an orphan branch with single file), > > This still spins up an VM, and actions/github-script run (I think) > nodejs, which is more resource intensive than git and sh script. > Above statement maybe wrong, I'm not interacting much with nodejs.
I was wrong, actions/checkout is also using nodejs, So, this actions/github-script actual reduces the total time for fetching the file ref-whitelist/ref-blacklist/allow-ref
Show 28 quoted lines
> > - 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');
>
> And this `indexOf` will check if our ref (exact) matchs (full line)
> with some white-list list, which is very limited.
> So people couldn't match by some pattern (grep can work).
>
> I haven't tested, but we may use part of above script to read a single
> file from a ref, and add another steps for "grep"/"sh"
> I'm not sure if that script will cost more resources than git-checkout
> or not. And is that solutions over-engineered?But this point still hold, now, I think using part of above script to read the file, and allow more custom logic in a separated steps maybe better solutions.
-- Danh