Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 7, 2020, 18:29 UTC
- Message-ID
- <xmqqeerv4n0q.fsf@gitster.c.googlers.com>
- In-Reply-To
- <20200507122549.GB3057274@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 7 quoted lines
> Yeah, I agree that all of the mechanisms for dealing with the unrelated > history are somewhat awkward. Another issue is that you can't just: > > git clone --single-branch -b refs/ci/config my-config > > to work on it, because "-b" wants only heads or tags (we could address > that by putting it in refs/heads/ci-config or similar).
I somehow don't think that it is such a huge issue, because I expect anybody who has legitimate interest in refs/ci/config to have a full clone of git.git anyway. So it is more like defining another remote.origin.fetch like this:
[remote "origin"] url = https://git.kernel.org/pub/scm/git/git.git/ fetch = +refs/heads/*:refs/remotes/origin/* + fetch = +refs/ci/config:refs/remotes/origin/ci-config
[remote "publish"] url = https://github.com/user/git/
and then do something like:
$ git worktree add -b ci-config ../git-ci-config origin/ci-config
$ cd ../git-ci-config
... hack hack hack ...
$ git push publish ci-config:refs/ci/config> If we do go the javascript route, perhaps it would make sense for > refs/ci/config to be a single blob containing a snippet of javascript > with several functions. And then we could just eval() that and call the > appropriate functions (if defined).
Yup.
Show 13 quoted lines
> Then a sample can live in the main repo with something like: > > # This file contains functions which will be run by the GitHub > # Actions CI script. > # > # You may customize it for your own fork by modifying it on any branch > # you like, and installing with: > # > # git push <remote> $(git rev-parse HEAD:ci/config):refs/ci/config > # > # [allow_ref() sample definition and documentation....] > > That sidesteps most of those issues.
Perhaps.