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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

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

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