{"thread":{"id":"53374","subject":"[PATCH] ci: respect the [skip ci] convention in our GitHub workflow \"CI/PR\"","startedAt":"2020-05-02T15:08:12Z","lastAt":"2020-05-09T01:23:13Z","messageCount":62,"participants":["Johannes Schindelin via GitGitGadget","Jeff King","Danh Doan","Junio C Hamano","Đoàn Trần Công Danh","Taylor Blau","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"396830","messageId":"pull.776.git.git.1588432087854.gitgitgadget@gmail.com","threadId":"53374","inReplyTo":null,"subject":"[PATCH] ci: respect the [skip ci] convention in our GitHub workflow \"CI/PR\"","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-05-02T15:08:07Z","receivedAt":"2020-05-02T15:08:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nIt might have been invented by Travis CI (at least it is described here:\nhttps://docs.travis-ci.com/user/customizing-the-build/#skipping-a-build)\nto avoid unnecessary builds: if the tip commit message (or for PR\nbuilds, the PR description) contains the needle `[skip ci]`, then the\nbuild is skipped.\n\nUnlike Azure Pipelines, GitHub workflows does not support that feature\nout of the box (at least not at the time of writing), but we can\nreinstate it manually.\n\nNote: GitHub workflows might implement this at some stage. In the least,\nthe desire for this feature is expressed, together with some history, at\nhttps://github.community/t5/GitHub-Actions/GitHub-Actions-does-not-respect-skip-ci/m-p/42834\n\nWhile it is the number five in the kudo ranking of the GitHub Actions\nposts, it might take a while given the current state of the world. In\nthe meantime let's do the manual thing.\n\nFollowing Travis CI's example, we also add special handling to exclude\nthe PR build when the PR title or description (or any other part of the\npull request information provided by the GitHub event) contains the\nneedle `[skip pr]`.\n\nNote: for technical reasons, a PR build will still run if a commit\nmessage contains the needle `[skip ci]` but neither PR title nor\ndescription contain the needle `[skip pr]`: for PR builds, the commit\nmessages are not part of the payload delivered via the event.\n\nSigned-off-by: Johannes Schindelin \n---\n ci: allow skipping CI/PR builds on GitHub\n \n It was mentioned to me that it might not be totally helpful to run all \n the builds whenever an in-progress branch is pushed to GitHub. For\n example, if a contributor has dozens of topic branches in flight, they\n might not want to have all of them built whenever a new end-of-day push\n happens.\n \n This patch tries to address that, by following the convention that I\n believe Travis CI invented: if a commit message contains the needle \n [skip ci], any CI build (i.e. a build triggered by a push) is skipped.\n Likewise, PR builds are skipped when the PR title and/or description\n contains [skip pr].\n \n Ideally, GitHub workflows will support this feature at some stage, but\n until then, we could have this (admittedly not very elegant) workaround.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-776%2Fdscho%2Fskip-ci-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-776/dscho/skip-ci-v1\nPull-Request: https://github.com/git/git/pull/776\n\n .github/workflows/main.yml | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex fd4df939b50..0e4a280d309 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -7,6 +7,7 @@ env:\n \n jobs:\n windows-build:\n+ if: \"!contains(toJSON(github.event.commits.*.message), '[skip ci]') && !contains(toJSON(github.event.pull_request), '[skip pr]')\"\n runs-on: windows-latest\n steps:\n - uses: actions/checkout@v1\n@@ -70,6 +71,7 @@ jobs:\n name: failed-tests-windows\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n vs-build:\n+ if: \"!contains(toJSON(github.event.commits.*.message), '[skip ci]') && !contains(toJSON(github.event.pull_request), '[skip pr]')\"\n env:\n MSYSTEM: MINGW64\n NO_PERL: 1\n@@ -154,6 +156,7 @@ jobs:\n ${{matrix.nr}} 10 t[0-9]*.sh)\n \"@\n regular:\n+ if: \"!contains(toJSON(github.event.commits.*.message), '[skip ci]') && !contains(toJSON(github.event.pull_request), '[skip pr]')\"\n strategy:\n matrix:\n vector:\n@@ -189,6 +192,7 @@ jobs:\n name: failed-tests-${{matrix.vector.jobname}}\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n dockerized:\n+ if: \"!contains(toJSON(github.event.commits.*.message), '[skip ci]') && !contains(toJSON(github.event.pull_request), '[skip pr]')\"\n strategy:\n matrix:\n vector:\n@@ -213,6 +217,7 @@ jobs:\n name: failed-tests-${{matrix.vector.jobname}}\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n static-analysis:\n+ if: \"!contains(toJSON(github.event.commits.*.message), '[skip ci]') && !contains(toJSON(github.event.pull_request), '[skip pr]')\"\n env:\n jobname: StaticAnalysis\n runs-on: ubuntu-latest\n@@ -221,6 +226,7 @@ jobs:\n - run: ci/install-dependencies.sh\n - run: ci/run-static-analysis.sh\n documentation:\n+ if: \"!contains(toJSON(github.event.commits.*.message), '[skip ci]') && !contains(toJSON(github.event.pull_request), '[skip pr]')\"\n env:\n jobname: Documentation\n runs-on: ubuntu-latest\n\nbase-commit: b34789c0b0d3b137f0bb516b417bd8d75e0cb306\n-- \ngitgitgadget\n"},{"id":"396863","messageId":"20200503093646.GC170902@coredump.intra.peff.net","threadId":"53374","inReplyTo":"pull.776.git.git.1588432087854.gitgitgadget@gmail.com","subject":"Re: [PATCH] ci: respect the [skip ci] convention in our GitHub workflow \"CI/PR\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-03T09:36:46Z","receivedAt":"2020-05-03T09:36:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 02, 2020 at 03:08:07PM +0000, Johannes Schindelin via GitGitGadget wrote:\n\n> It was mentioned to me that it might not be totally helpful to run all \n> the builds whenever an in-progress branch is pushed to GitHub. For\n> example, if a contributor has dozens of topic branches in flight, they\n> might not want to have all of them built whenever a new end-of-day push\n> happens.\n\nAs I was probably (one of) the mentioners here, thank you for looking\ninto this. This definitely _helps_, and if you don't want to go further\nI could certainly make do with it[1].\n\nBut here are some thoughts on what a more ideal solution would look\nlike (to me, anyway).\n\nWhat I'd _most_ like is a separately-maintained list of branches (or\nbranch patterns) on which to run CI. I mostly care about just testing\nmy personal equivalent of \"next\" (which is really \"next\" plus my stable\ntopics), and I'd probably only list that branch. Plus potentially a\nspecial CI branch that I'd use when chasing down a failure that I can't\nreproduce locally.\n\nBut I don't think there's any good way to implement that via GitHub\nActions. I thought perhaps we could pull data from a different branch in\nthe same repo, but referring to external \"Actions\" seems to require a\nfull repo name (and obviously putting git/git in that name doesn't help\nanybody who's trying to override something in a fork).\n\nAnother alternative: could we trigger CI based on branch-names? Locally,\nI call my unstable branches \"jk/something-wip\", and I'd like to skip all\nof the \"-wip\" branches. That's basically equivalent to \"[skip ci]\" in\nthat I could just amend the tip commit of the -wip branches to say \"skip\nci\". But what if we flipped the default to _not_ build? I.e.:\n\n - continue to build all pull requests; if you opened one, you're\n serious enough to have other people look and should get CI feedback\n\n - build branches with a few well-known names or patterns. Maybe\n names like \"master\"? Or maybe \"refs/heads/build-ci/*\"? Or maybe\n anything in \"refs/heads//*\"? We'd have to decide on a\n convention as a community.\n\n - do not build anything else; we have no idea if somebody in a fork is\n just pushing up a work in progress or not, and they may be surprised\n to get a CI failure notification back.\n\nI'm not sure whether we want to be building all of the individual topics\nin gitster/git or not. In theory that provides more information, but I'm\nnot sure if anybody is looking at them (and all of the notifications\nwould go to Junio anyway).\n\nMy ideas aren't really developed, but I guess what I'm wondering\nforemost is whether other people are thinking along the same lines.\n\n> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> index fd4df939b50..0e4a280d309 100644\n> --- a/.github/workflows/main.yml\n> +++ b/.github/workflows/main.yml\n> @@ -7,6 +7,7 @@ env:\n> \n> jobs:\n> windows-build:\n> + if: \"!contains(toJSON(github.event.commits.*.message), '[skip ci]') && !contains(toJSON(github.event.pull_request), '[skip pr]')\"\n\nIt's unfortunate to have to repeat this in every job, as opposed to in\nthe \"on\" event block, but I don't think that block is flexible enough to\ndo what we want here.\n\nI don't know very much about Actions, but the code looks correct to me.\n\n-Peff\n\n[1] My current workaround is even more horrendous: I've turned off\n Actions entirely in peff/git, and then I separately push branches I\n want CI on into a separate repository. But that repo can't be a fork\n of git/git, because I already have one! So I now have an extra\n \"git-ci\" repo that isn't connected to anything. Yuck.\n"},{"id":"396871","messageId":"20200503120546.GB28680@danh.dev","threadId":"53374","inReplyTo":"20200503093646.GC170902@coredump.intra.peff.net","subject":"Re: [PATCH] ci: respect the [skip ci] convention in our GitHub workflow \"CI/PR\"","fromName":"Danh Doan","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-03T12:05:46Z","receivedAt":"2020-05-03T12:05:52Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-03 05:36:46-0400, Jeff King wrote:\n> On Sat, May 02, 2020 at 03:08:07PM +0000, Johannes Schindelin via GitGitGadget wrote:\n> \n> > It was mentioned to me that it might not be totally helpful to run all \n> > the builds whenever an in-progress branch is pushed to GitHub. For\n> > example, if a contributor has dozens of topic branches in flight, they\n> > might not want to have all of them built whenever a new end-of-day push\n> > happens.\n> \n> As I was probably (one of) the mentioners here, thank you for looking\n> into this. This definitely _helps_, and if you don't want to go further\n> I could certainly make do with it[1].\n> \n> But here are some thoughts on what a more ideal solution would look\n> like (to me, anyway).\n> \n> What I'd _most_ like is a separately-maintained list of branches (or\n> branch patterns) on which to run CI. I mostly care about just testing\n> my personal equivalent of \"next\" (which is really \"next\" plus my stable\n> topics), and I'd probably only list that branch. Plus potentially a\n> special CI branch that I'd use when chasing down a failure that I can't\n> reproduce locally.\n> \n> But I don't think there's any good way to implement that via GitHub\n> Actions. I thought perhaps we could pull data from a different branch in\n> the same repo, but referring to external \"Actions\" seems to require a\n> full repo name (and obviously putting git/git in that name doesn't help\n> anybody who's trying to override something in a fork).\n> \n> Another alternative: could we trigger CI based on branch-names? Locally,\n> I call my unstable branches \"jk/something-wip\", and I'd like to skip all\n> of the \"-wip\" branches. That's basically equivalent to \"[skip ci]\" in\n> that I could just amend the tip commit of the -wip branches to say \"skip\n> ci\". But what if we flipped the default to _not_ build? I.e.:\n> \n> - continue to build all pull requests; if you opened one, you're\n> serious enough to have other people look and should get CI feedback\n> \n> - build branches with a few well-known names or patterns. Maybe\n> names like \"master\"? Or maybe \"refs/heads/build-ci/*\"? Or maybe\n> anything in \"refs/heads//*\"? We'd have to decide on a\n> convention as a community.\n\nI think this is better approach for Junio, and we can help people opt\nin by asking them to push into \"for-ci/.\n\nThis is my proposal for it:\n\n------------------8<-------------\nFrom: =?UTF-8?q?=C4=90o=C3=A0n=20Tr=E1=BA=A7n=20C=C3=B4ng=20Danh?=\n \nDate: Sun, 3 May 2020 18:56:50 +0700\nSubject: [PATCH] CI: GitHub: limit GitHub Action to intergration branches\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\nSigned-off-by: Đoàn Trần Công Danh \n---\n .github/workflows/main.yml | 15 ++++++++++++++-\n 1 file changed, 14 insertions(+), 1 deletion(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex fd4df939b5..303393ba73 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -1,6 +1,19 @@\n name: CI/PR\n \n-on: [push, pull_request]\n+on:\n+ pull_request:\n+ branches:\n+ - '*'\n+ push:\n+ branches:\n+ - maint\n+ - master\n+ - next\n+ - jch\n+ - pu\n+ - 'for-ci/**'\n+ tags:\n+ - '*'\n \n env:\n DEVELOPER: 1\n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"396874","messageId":"xmqqa72pj7ag.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200503093646.GC170902@coredump.intra.peff.net","subject":"Re: [PATCH] ci: respect the [skip ci] convention in our GitHub workflow \"CI/PR\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-03T16:46:15Z","receivedAt":"2020-05-03T16:46:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I'm not sure whether we want to be building all of the individual topics\n> in gitster/git or not. In theory that provides more information, but I'm\n> not sure if anybody is looking at them (and all of the notifications\n> would go to Junio anyway).\n\nI do not think I am letting GitHub notifications for gitster/* come\nto my mailbox, so it is quite possible that many have piled up there\nwithout anybody (not even me) seeing them.\n\nI won't be locally able to notice breakages introduced by an\nindividual topic to an environment I do not have access to, and\nbuilding these topics with GitHub Actions may reveal which ones\nbreak, say, vsbuild, but I won't be debugging and fixing such issues\nmyself anyway, so at least to me it is useless to run build there.\n\nI think I agree with your outline, i.e. build pull requests to help\ncontributors, and build public integration branches to help the\nproject as a whole.\n\nThanks.\n"},{"id":"396906","messageId":"20200504150105.GB11373@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200503120546.GB28680@danh.dev","subject":"Re: [PATCH] ci: respect the [skip ci] convention in our GitHub workflow \"CI/PR\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-04T15:01:05Z","receivedAt":"2020-05-04T15:01:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, May 03, 2020 at 07:05:46PM +0700, Danh Doan wrote:\n\n> This is my proposal for it:\n> [...]\n> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> index fd4df939b5..303393ba73 100644\n> --- a/.github/workflows/main.yml\n> +++ b/.github/workflows/main.yml\n> @@ -1,6 +1,19 @@\n> name: CI/PR\n> \n> -on: [push, pull_request]\n> +on:\n> + pull_request:\n> + branches:\n> + - '*'\n> + push:\n> + branches:\n> + - maint\n> + - master\n> + - next\n> + - jch\n> + - pu\n> + - 'for-ci/**'\n> + tags:\n> + - '*'\n\nYeah, this seems quite reasonable to me. I'd just add a refspec to push\na duplicate of branches I'm interested in running CI on to for-ci.\n\n-Peff\n"},{"id":"396912","messageId":"cover.1588607262.git.congdanhqx@gmail.com","threadId":"53374","inReplyTo":"20200504150105.GB11373@coredump.intra.peff.net","subject":"[PATCH v2 0/2] Limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-04T15:49:30Z","receivedAt":"2020-05-04T15:49:47Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"It seems like there's at least one contributor like this proposal.\n\n> Yeah, this seems quite reasonable to me. I'd just add a refspec to push\n> a duplicate of branches I'm interested in running CI on to for-ci.\n\nI've tweaked the commit message for the proposal and added a new patch to\nadvertise GitHub Actions to our friends.\n\nWith this series applied, we will trigger GitHub Actions CI for those branches\nonly:\n\n- 5 integration branches: maint, master, next, jch, and pu\n- Contributors' opted-in branches: 'for-ci/**'\n\n\nĐoàn Trần Công Danh (2):\n CI: limit GitHub Actions to designated branches\n SubmittingPatches: advertise GitHub Actions CI\n\n .github/workflows/main.yml | 14 +++++++++++++-\n Documentation/SubmittingPatches | 5 +++++\n 2 files changed, 18 insertions(+), 1 deletion(-)\n\nRange-diff against v1:\n1: 106620b2d8 ! 1: 73de97dfeb CI: GitHub: limit GitHub Action to intergration branches\n @@ Metadata\n Author: Đoàn Trần Công Danh \n \n ## Commit message ##\n - CI: GitHub: limit GitHub Action to intergration branches\n + CI: limit GitHub Actions to designated branches\n +\n + Git's maintainer usually don't have enough time to debug the failure of\n + invidual feature branch, they usually want to look at intergration\n + branches.\n +\n + Contributors now can have GitHub Actions as an opt-in option,\n + should they want to check their code, they will push into designated\n + branch.\n \n Signed-off-by: Đoàn Trần Công Danh \n \n @@ .github/workflows/main.yml\n +on:\n + pull_request:\n + branches:\n -+ - '*'\n ++ - '**'\n + push:\n + branches:\n + - maint\n-: ---------- > 2: 24a8fefe5a SubmittingPatches: advertise GitHub Actions CI\n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"396913","messageId":"73de97dfebfccabe9f1bf32ea41aea5008a949cd.1588607262.git.congdanhqx@gmail.com","threadId":"53374","inReplyTo":"cover.1588607262.git.congdanhqx@gmail.com","subject":"[PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-04T15:49:31Z","receivedAt":"2020-05-04T15:49:48Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Git's maintainer usually don't have enough time to debug the failure of\ninvidual feature branch, they usually want to look at intergration\nbranches.\n\nContributors now can have GitHub Actions as an opt-in option,\nshould they want to check their code, they will push into designated\nbranch.\n\nSigned-off-by: Đoàn Trần Công Danh \n---\n .github/workflows/main.yml | 14 +++++++++++++-\n 1 file changed, 13 insertions(+), 1 deletion(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex fd4df939b5..ea43b03092 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -1,6 +1,18 @@\n name: CI/PR\n \n-on: [push, pull_request]\n+on:\n+ pull_request:\n+ branches:\n+ - '**'\n+ push:\n+ branches:\n+ - maint\n+ - master\n+ - next\n+ - jch\n+ - pu\n+ tags:\n+ - '*'\n \n env:\n DEVELOPER: 1\n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"396914","messageId":"24a8fefe5add61d557a29f070bd2ca0d0f43d844.1588607262.git.congdanhqx@gmail.com","threadId":"53374","inReplyTo":"cover.1588607262.git.congdanhqx@gmail.com","subject":"[PATCH v2 2/2] SubmittingPatches: advertise GitHub Actions CI","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-04T15:49:32Z","receivedAt":"2020-05-04T15:49:51Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"From 889cacb689 (ci: configure GitHub Actions for CI/PR, 2020-04-11),\nGitHub Actions was introduced as an alternative CI system for Git\nproject.\n\nLet's advertise it to Git's contributors to help them test Git on\nvarious platforms before submitting to Git.\n\nSigned-off-by: Đoàn Trần Công Danh \n---\n Documentation/SubmittingPatches | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 4515cab519..741867dfe3 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -78,6 +78,11 @@ on open source projects), you can use their Travis CI integration to\n test your changes on Linux, Mac (and hopefully soon Windows). See\n GitHub-Travis CI hints section for details.\n \n+Alternately, you can use GitHub Actions (which supports testing your changes\n+on Linux, macOS, and Windows) by pushing into a branch whose name starts\n+with \"for-ci/\" or opening a GitHub's Pull Request against\n+https://github.com/git/git.git\n+\n Do not forget to update the documentation to describe the updated\n behavior and make sure that the resulting documentation set formats\n well (try the Documentation/doc-diff script).\n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"396923","messageId":"20200504162311.GE12842@coredump.intra.peff.net","threadId":"53374","inReplyTo":"73de97dfebfccabe9f1bf32ea41aea5008a949cd.1588607262.git.congdanhqx@gmail.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-04T16:23:11Z","receivedAt":"2020-05-04T16:23:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 04, 2020 at 10:49:31PM +0700, Đoàn Trần Công Danh wrote:\n\n> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> index fd4df939b5..ea43b03092 100644\n> --- a/.github/workflows/main.yml\n> +++ b/.github/workflows/main.yml\n> @@ -1,6 +1,18 @@\n> name: CI/PR\n> \n> -on: [push, pull_request]\n> +on:\n> + pull_request:\n> + branches:\n> + - '**'\n\nDoing \"**\" here makes sense to catch everything (it would be even better\nif we could just say \"everything with a pull request\" by omitting the\nbranch filter entirely, but maybe that's not possible).\n\n> + tags:\n> + - '*'\n\nWould we want that here, too? I guess nobody is likely to push\n\"foo/v1.2.3\".\n\nOr on the flip side, would we want to tighten this? If I push a tag\n\"wip\", I probably don't want it built. Probably the right rule is\n\"annotated tags only\", but I suspect that's not possible.\n\n> + push:\n> + branches:\n> + - maint\n> + - master\n> + - next\n> + - jch\n> + - pu\n\nWhat happened to \"for-ci\" (presumably \"for-ci/**\")?\n\n-Peff\n"},{"id":"396928","messageId":"xmqqmu6nhd1k.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"24a8fefe5add61d557a29f070bd2ca0d0f43d844.1588607262.git.congdanhqx@gmail.com","subject":"Re: [PATCH v2 2/2] SubmittingPatches: advertise GitHub Actions CI","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-04T16:37:11Z","receivedAt":"2020-05-04T16:37:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Đoàn Trần Công Danh writes:\n\n> +Alternately, you can use GitHub Actions (which supports testing your changes\n> +on Linux, macOS, and Windows) by pushing into a branch whose name starts\n> +with \"for-ci/\" or opening a GitHub's Pull Request against\n> +https://github.com/git/git.git\n\nCan you tighten the description of \"for-ci/\" a bit? It's not like\nthe convention is offered in _any_ repository, but it is active only\nif you push to a fork of git.git, right? If your fork is a fork of\na fork, what happens (e.g. github.com/gitster/git is marked as a\nfork of git/git; when somebody forks from gitster/git, would they\nalso get the for-ci/ convention)?\n\nThanks.\n\n"},{"id":"396997","messageId":"20200504215824.GC45250@syl.local","threadId":"53374","inReplyTo":"20200504162311.GE12842@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-05-04T21:58:24Z","receivedAt":"2020-05-04T21:58:28Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, May 04, 2020 at 12:23:11PM -0400, Jeff King wrote:\n> On Mon, May 04, 2020 at 10:49:31PM +0700, Đoàn Trần Công Danh wrote:\n>\n> > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> > index fd4df939b5..ea43b03092 100644\n> > --- a/.github/workflows/main.yml\n> > +++ b/.github/workflows/main.yml\n> > @@ -1,6 +1,18 @@\n> > name: CI/PR\n> >\n> > -on: [push, pull_request]\n> > +on:\n> > + pull_request:\n> > + branches:\n> > + - '**'\n>\n> Doing \"**\" here makes sense to catch everything (it would be even better\n> if we could just say \"everything with a pull request\" by omitting the\n> branch filter entirely, but maybe that's not possible).\n>\n> > + tags:\n> > + - '*'\n>\n> Would we want that here, too? I guess nobody is likely to push\n> \"foo/v1.2.3\".\n>\n> Or on the flip side, would we want to tighten this? If I push a tag\n> \"wip\", I probably don't want it built. Probably the right rule is\n> \"annotated tags only\", but I suspect that's not possible.\n>\n> > + push:\n> > + branches:\n> > + - maint\n> > + - master\n> > + - next\n> > + - jch\n> > + - pu\n>\n> What happened to \"for-ci\" (presumably \"for-ci/**\")?\n\nHuh; I'm not sure that I'm sold on the idea of a 'for-ci' namespace\nhere. In addition to running 'make test' on patches locally before I\nsend them, I find it tremendously convenient for GitHub to run them for\nme when I push 'tb/' branches up to 'ttaylorr/git'.\n\nSo, while the above is more-or-less what I'd expect the monitored list\nof branches to look like (at least, ignoring the missing 'for-ci/**'\nbits), I wish that I could also build every branch that I push up to my\nfork.\n\nOf course, I don't want to maintain a one-patch difference between\nttaylorr/git@master and git/git@master, so I wonder if we could get a\nlittle more creative with these rules and actually run Actions on\n*every* branch, but introduce a new first step which stops the rest of\nthe actions run (so that in practice we're not running CI on\nnon-integration branches in Junio's tree).\n\nI figure that we need something more flexible than the 'push.branches'\nlist, but I'd be very curious to hear if something like what I'm\ndescribing is possible.\n\n> -Peff\n\nThanks,\nTaylor\n"},{"id":"397004","messageId":"xmqqzhane2ir.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200504215824.GC45250@syl.local","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-04T22:52:44Z","receivedAt":"2020-05-04T22:52:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> Huh; I'm not sure that I'm sold on the idea of a 'for-ci' namespace\n> here. In addition to running 'make test' on patches locally before I\n> send them, I find it tremendously convenient for GitHub to run them for\n> me when I push 'tb/' branches up to 'ttaylorr/git'.\n>\n> So, while the above is more-or-less what I'd expect the monitored list\n> of branches to look like (at least, ignoring the missing 'for-ci/**'\n> bits), I wish that I could also build every branch that I push up to my\n> fork.\n>\n> Of course, I don't want to maintain a one-patch difference between\n> ttaylorr/git@master and git/git@master, so I wonder if we could get a\n> little more creative with these rules and actually run Actions on\n> *every* branch, but introduce a new first step which stops the rest of\n> the actions run (so that in practice we're not running CI on\n> non-integration branches in Junio's tree).\n\nHmph, what are we trying to avoid by using the for-ci/ convention?\n\nIf this is only a reaction to what I said earlier (i.e. \"building\neverything in github.com/gitster/git/ has no value to me\"), then I\nsuspect it may be an over-engineered solution to a problem that does\nnot exist, and harms people like you. I could just go there and\nturn off GitHub Actions for that repository instead.\n\nOr are there more issues being addressed with the \"testing branches\nare opt-in, unless a pull request against git/git explicitly says it\nis ready to be tested\" approach?\n\n"},{"id":"397013","messageId":"20200504231544.GJ45250@syl.local","threadId":"53374","inReplyTo":"xmqqzhane2ir.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-05-04T23:15:44Z","receivedAt":"2020-05-04T23:15:49Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, May 04, 2020 at 03:52:44PM -0700, Junio C Hamano wrote:\n> Taylor Blau writes:\n>\n> > Huh; I'm not sure that I'm sold on the idea of a 'for-ci' namespace\n> > here. In addition to running 'make test' on patches locally before I\n> > send them, I find it tremendously convenient for GitHub to run them for\n> > me when I push 'tb/' branches up to 'ttaylorr/git'.\n> >\n> > So, while the above is more-or-less what I'd expect the monitored list\n> > of branches to look like (at least, ignoring the missing 'for-ci/**'\n> > bits), I wish that I could also build every branch that I push up to my\n> > fork.\n> >\n> > Of course, I don't want to maintain a one-patch difference between\n> > ttaylorr/git@master and git/git@master, so I wonder if we could get a\n> > little more creative with these rules and actually run Actions on\n> > *every* branch, but introduce a new first step which stops the rest of\n> > the actions run (so that in practice we're not running CI on\n> > non-integration branches in Junio's tree).\n>\n> Hmph, what are we trying to avoid by using the for-ci/ convention?\n>\n> If this is only a reaction to what I said earlier (i.e. \"building\n> everything in github.com/gitster/git/ has no value to me\"), then I\n> suspect it may be an over-engineered solution to a problem that does\n> not exist, and harms people like you. I could just go there and\n> turn off GitHub Actions for that repository instead.\n\nIt is a reaction to that, yes. It would be nice to have a middle-ground\nwhere you can run Actions on the official integration branches, but\ncontributors such as myself run Actions on *every* branch of their fork.\n\nIt does feel over-engineered, yes. I would not be surprised if Actions\nsupports something like this more directly, and I just don't know about\nit.\n\n> Or are there more issues being addressed with the \"testing branches\n> are opt-in, unless a pull request against git/git explicitly says it\n> is ready to be tested\" approach?\n\nThanks,\nTaylor\n"},{"id":"397016","messageId":"20200504233512.GA39798@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200504231544.GJ45250@syl.local","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-04T23:35:12Z","receivedAt":"2020-05-04T23:35:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 04, 2020 at 05:15:44PM -0600, Taylor Blau wrote:\n\n> > If this is only a reaction to what I said earlier (i.e. \"building\n> > everything in github.com/gitster/git/ has no value to me\"), then I\n> > suspect it may be an over-engineered solution to a problem that does\n> > not exist, and harms people like you. I could just go there and\n> > turn off GitHub Actions for that repository instead.\n> \n> It is a reaction to that, yes. It would be nice to have a middle-ground\n> where you can run Actions on the official integration branches, but\n> contributors such as myself run Actions on *every* branch of their fork.\n\nThe problem is that there is no way for people to _not_ run on every\nbranch of their fork, then. It is either every branch or no branches.\n\nBy choosing a prefix, it gives people the option to choose. But it does\nplace the burden on them of adding an extra refspec:\n\n refs/heads/*:refs/heads/for-ci/*\n\nor similar. I don't like it, but I don't see any other way to let people\nchoose some branches but not others (that doesn't involve a one-line\nyaml change at the beginning of every branch, which is an even higher\nburden).\n\n-Peff\n"},{"id":"397017","messageId":"20200504233634.GB39798@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200504215824.GC45250@syl.local","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-04T23:36:34Z","receivedAt":"2020-05-04T23:36:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 04, 2020 at 03:58:24PM -0600, Taylor Blau wrote:\n\n> Huh; I'm not sure that I'm sold on the idea of a 'for-ci' namespace\n> here. In addition to running 'make test' on patches locally before I\n> send them, I find it tremendously convenient for GitHub to run them for\n> me when I push 'tb/' branches up to 'ttaylorr/git'.\n> \n> So, while the above is more-or-less what I'd expect the monitored list\n> of branches to look like (at least, ignoring the missing 'for-ci/**'\n> bits), I wish that I could also build every branch that I push up to my\n> fork.\n> \n> Of course, I don't want to maintain a one-patch difference between\n> ttaylorr/git@master and git/git@master, so I wonder if we could get a\n> little more creative with these rules and actually run Actions on\n> *every* branch, but introduce a new first step which stops the rest of\n> the actions run (so that in practice we're not running CI on\n> non-integration branches in Junio's tree).\n\nI don't understand what that would accomplish. If we ran the actions on\nevery branch but stopped the run, then you wouldn't get the CI results\nyou want. What am I missing?\n\n-Peff\n"},{"id":"397023","messageId":"20200505002055.GC64230@syl.local","threadId":"53374","inReplyTo":"20200504233634.GB39798@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-05-05T00:20:55Z","receivedAt":"2020-05-05T00:21:04Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, May 04, 2020 at 07:36:34PM -0400, Jeff King wrote:\n> On Mon, May 04, 2020 at 03:58:24PM -0600, Taylor Blau wrote:\n>\n> > Huh; I'm not sure that I'm sold on the idea of a 'for-ci' namespace\n> > here. In addition to running 'make test' on patches locally before I\n> > send them, I find it tremendously convenient for GitHub to run them for\n> > me when I push 'tb/' branches up to 'ttaylorr/git'.\n> >\n> > So, while the above is more-or-less what I'd expect the monitored list\n> > of branches to look like (at least, ignoring the missing 'for-ci/**'\n> > bits), I wish that I could also build every branch that I push up to my\n> > fork.\n> >\n> > Of course, I don't want to maintain a one-patch difference between\n> > ttaylorr/git@master and git/git@master, so I wonder if we could get a\n> > little more creative with these rules and actually run Actions on\n> > *every* branch, but introduce a new first step which stops the rest of\n> > the actions run (so that in practice we're not running CI on\n> > non-integration branches in Junio's tree).\n>\n> I don't understand what that would accomplish. If we ran the actions on\n> every branch but stopped the run, then you wouldn't get the CI results\n> you want. What am I missing?\n\nThat on forks of git/git we *would't* stop the run for non-integration\nbranches, i.e., that we'd have something like:\n\n * Actions is running on all branches, of all forks, all the time.\n\n * If a branch is pushed to git/git, and it's not an integration\n branch, the run is aborted early.\n\n * If a branch is pushed to a fork of git/git, it's allowed to run no\n matter what.\n\nMaybe it's an over-engineered solution to a problem that we don't\nhave, though. Junio seems happy to simply disable Actions on git/git.\nOTOH, I think it would be OK to skip the second bullet point, and\nhave Junio disable Actions notifications.\n\n/shrug\n\n> -Peff\n\nThanks,\nTaylor\n"},{"id":"397024","messageId":"xmqqv9lbcjp4.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200504233512.GA39798@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-05T00:24:39Z","receivedAt":"2020-05-05T00:24:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, May 04, 2020 at 05:15:44PM -0600, Taylor Blau wrote:\n>\n>> > If this is only a reaction to what I said earlier (i.e. \"building\n>> > everything in github.com/gitster/git/ has no value to me\"), then I\n>> > suspect it may be an over-engineered solution to a problem that does\n>> > not exist, and harms people like you. I could just go there and\n>> > turn off GitHub Actions for that repository instead.\n>> \n>> It is a reaction to that, yes. It would be nice to have a middle-ground\n>> where you can run Actions on the official integration branches, but\n>> contributors such as myself run Actions on *every* branch of their fork.\n>\n> The problem is that there is no way for people to _not_ run on every\n> branch of their fork, then. It is either every branch or no branches.\n\nOK.\n\n> .... I don't like it, but I don't see any other way to let people\n> choose some branches but not others (that doesn't involve a one-line\n> yaml change at the beginning of every branch, which is an even higher\n> burden).\n\nTrue, and having to mark a commit object with \"do not run CI on this\",\nwhich is what I heard Travis does, is even worse.\n\n"},{"id":"397025","messageId":"20200505003438.GA927@danh.dev","threadId":"53374","inReplyTo":"20200504162311.GE12842@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-05T00:34:38Z","receivedAt":"2020-05-05T00:34:42Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-04 12:23:11-0400, Jeff King wrote:\n> On Mon, May 04, 2020 at 10:49:31PM +0700, Đoàn Trần Công Danh wrote:\n> Doing \"**\" here makes sense to catch everything (it would be even better\n> if we could just say \"everything with a pull request\" by omitting the\n> branch filter entirely, but maybe that's not possible).\n\nWhen I was doing this, I couldn't create a fork of my fork to check\nthe syntax for GitHub PR. So, I pick a safe step.\n\nTurn out, I can create PR against my own fork.\nAnd, it's possible to omit the branch filter entirely.\n\n> > + tags:\n> > + - '*'\n> \n> Would we want that here, too? I guess nobody is likely to push\n> \"foo/v1.2.3\".\n> \n> Or on the flip side, would we want to tighten this? If I push a tag\n> \"wip\", I probably don't want it built. Probably the right rule is\n> \"annotated tags only\", but I suspect that's not possible.\n\nFrom my reading, GitHub Actions only accepts filter by refname.\n\nFrom GitHub manual, we can limit tags selection by: \n-------------8<------\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex adf8824af1..9bba0ce068 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -11,7 +11,8 @@ on:\n - pu\n - 'for-ci**'\n tags:\n- - '*'\n+ - '**'\n+ - '!**wip**'\n \n env:\n DEVELOPER: 1\n---------------->8-------------\n\nBut, I'm running into GitHub internal error with this snippet.\nI'll look into it later.\n\n> \n> > + push:\n> > + branches:\n> > + - maint\n> > + - master\n> > + - next\n> > + - jch\n> > + - pu\n> \n> What happened to \"for-ci\" (presumably \"for-ci/**\")?\n\nHm, it was lost when I created a lot of branch for testing and I send the incorrect one out.\nIt'll be correct next time.\n\n-- \nDanh\n"},{"id":"397027","messageId":"20200505004603.GB927@danh.dev","threadId":"53374","inReplyTo":"xmqqmu6nhd1k.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 2/2] SubmittingPatches: advertise GitHub Actions CI","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-05T00:46:03Z","receivedAt":"2020-05-05T00:46:10Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-04 09:37:11-0700, Junio C Hamano wrote:\n> Đoàn Trần Công Danh writes:\n> \n> > +Alternately, you can use GitHub Actions (which supports testing your changes\n> > +on Linux, macOS, and Windows) by pushing into a branch whose name starts\n> > +with \"for-ci/\" or opening a GitHub's Pull Request against\n> > +https://github.com/git/git.git\n> \n> Can you tighten the description of \"for-ci/\" a bit? It's not like\n> the convention is offered in _any_ repository, but it is active only\n> if you push to a fork of git.git, right?\n\nThe convention will work in any repository with\n\"$TOPDIR/.github/workflows/*.yml\" exists.\nSince GitHub Actions will look into the file \".github/workflows/*.yml\"\nin current repository.\n\n> If your fork is a fork of\n> a fork, what happens (e.g. github.com/gitster/git is marked as a\n> fork of git/git; when somebody forks from gitster/git, would they\n> also get the for-ci/ convention)?\n\nYes, they'll get that convention.\n\n-- \nDanh\n"},{"id":"397111","messageId":"cover.1588695295.git.congdanhqx@gmail.com","threadId":"53374","inReplyTo":"cover.1588607262.git.congdanhqx@gmail.com","subject":"[PATCH v3 0/3] Provide option to opt in/out GitHub Actions","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-05T16:26:38Z","receivedAt":"2020-05-05T16:26:52Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"It seems like there're 2 schools for GitHub Actions,\n- Opt-in by using some specific patterns\n- Opt-out by using some specific patterns\n\nI tried to help everyone happy, but with my current knowledge, I couldn't.\n\nThis series should be 2 patches only.\nI provide the [3/3] as a fix-up for [2/3].\n\nShould we conclude that it's over-engineered, please drop [3/3].\nShould we think it's OK to go that route, please fix-up [3/3] into [2/3].\n\nHopefully, we can get into some agreement on this matter.\n\nI'm not include range-diff/inter-diff against v2 since I reorder the patches,\nand [3/3] is meant for discussion.\n\n\nĐoàn Trần Công Danh (3):\n SubmittingPatches: advertise GitHub Actions CI\n CI: limit GitHub Actions to designated branches\n fixup! CI: limit GitHub Actions to designated branches\n\n .github/workflows/main.yml | 82 ++++++++++++++++++++++++++++++++-\n Documentation/SubmittingPatches | 6 +++\n 2 files changed, 87 insertions(+), 1 deletion(-)\n\n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"397112","messageId":"48752d8b164bc0b11f4d82016415811a0b2bf08b.1588695295.git.congdanhqx@gmail.com","threadId":"53374","inReplyTo":"cover.1588695295.git.congdanhqx@gmail.com","subject":"[PATCH v3 1/3] SubmittingPatches: advertise GitHub Actions CI","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-05T16:26:39Z","receivedAt":"2020-05-05T16:26:53Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"From 889cacb689 (ci: configure GitHub Actions for CI/PR, 2020-04-11),\nGitHub Actions was introduced as an alternative CI system for Git\nproject.\n\nLet's advertise it to Git's contributors to help them test Git on\nvarious platforms before submitting to Git.\n\nSigned-off-by: Đoàn Trần Công Danh \n---\n Documentation/SubmittingPatches | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 4515cab519..8686318550 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -78,6 +78,11 @@ on open source projects), you can use their Travis CI integration to\n test your changes on Linux, Mac (and hopefully soon Windows). See\n GitHub-Travis CI hints section for details.\n \n+Alternately, you can use GitHub Actions (which supports testing your changes\n+on Linux, macOS, and Windows) by pushing into a branch in your fork\n+or opening a GitHub's Pull Request against\n+https://github.com/git/git.git or a fork of that repository.\n+\n Do not forget to update the documentation to describe the updated\n behavior and make sure that the resulting documentation set formats\n well (try the Documentation/doc-diff script).\n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"397113","messageId":"a4c6f687c0a8ce55863a19a1c4048438f02803b5.1588695295.git.congdanhqx@gmail.com","threadId":"53374","inReplyTo":"cover.1588695295.git.congdanhqx@gmail.com","subject":"[PATCH v3 2/3] CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-05T16:26:40Z","receivedAt":"2020-05-05T16:26:55Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Git's maintainer usually don't have enough time to debug the failure of\ninvidual feature branch, they usually want to look at intergration\nbranches only.\n\nContributors now can have GitHub Actions as an opt-in option,\nshould they want to check their code, they will push into designated\nbranch.\n\nSigned-off-by: Đoàn Trần Công Danh \n---\n .github/workflows/main.yml | 14 +++++++++++++-\n Documentation/SubmittingPatches | 3 ++-\n 2 files changed, 15 insertions(+), 2 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex fd4df939b5..9bba0ce068 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -1,6 +1,18 @@\n name: CI/PR\n \n-on: [push, pull_request]\n+on:\n+ pull_request:\n+ push:\n+ branches:\n+ - maint\n+ - master\n+ - next\n+ - jch\n+ - pu\n+ - 'for-ci**'\n+ tags:\n+ - '**'\n+ - '!**wip**'\n \n env:\n DEVELOPER: 1\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 8686318550..e516b080df 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -79,7 +79,8 @@ test your changes on Linux, Mac (and hopefully soon Windows). See\n GitHub-Travis CI hints section for details.\n \n Alternately, you can use GitHub Actions (which supports testing your changes\n-on Linux, macOS, and Windows) by pushing into a branch in your fork\n+on Linux, macOS, and Windows) by pushing into a branch whose name starts\n+with \"for-ci\", or a tag whose name doesn't have `wip`,\n or opening a GitHub's Pull Request against\n https://github.com/git/git.git or a fork of that repository.\n \n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"397114","messageId":"a2e548b683cd584fd686a44e1d7f3473943fc73f.1588695295.git.congdanhqx@gmail.com","threadId":"53374","inReplyTo":"cover.1588695295.git.congdanhqx@gmail.com","subject":"[PATCH v3 3/3] fixup! CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-05T16:26:41Z","receivedAt":"2020-05-05T16:27:01Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"Here is the patch to for discussion.\n\nShould we want to enable GitHub Action for all repo-s, except git/git\nand gitster/git. We'll want to have this patch fix-up to the previous\none.\n\nWith this patch merged, contributors will need to opt-out by push to\na branch/tag with \"wip\" anywhere in the refname.\n\nNote that, integration branches (maint, master, next, jch, pu) will\nalways be built, regardless of repo.\nSince the current condition is ugly enough, and I find it's very hard to\nwrap my head around those condition.\n\nShould this patch get fixing up into previous one, please remove the second\nparagraph in the body of previous patch.\n\nThanks.\n\nSigned-off-by: Đoàn Trần Công Danh \n---\n .github/workflows/main.yml | 80 ++++++++++++++++++++++++++++++---\n Documentation/SubmittingPatches | 4 +-\n 2 files changed, 76 insertions(+), 8 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 9bba0ce068..81dfa3d228 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -4,12 +4,8 @@ on:\n pull_request:\n push:\n branches:\n- - maint\n- - master\n- - next\n- - jch\n- - pu\n- - 'for-ci**'\n+ - '**'\n+ - '!**wip**'\n tags:\n - '**'\n - '!**wip**'\n@@ -19,6 +15,15 @@ env:\n \n jobs:\n windows-build:\n+ if: >-\n+ ${{\n+ (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n+ github.ref == 'refs/heads/maint' ||\n+ github.ref == 'refs/heads/master' ||\n+ github.ref == 'refs/heads/next' ||\n+ github.ref == 'refs/heads/jch' ||\n+ github.ref == 'refs/heads/pu'\n+ }}\n runs-on: windows-latest\n steps:\n - uses: actions/checkout@v1\n@@ -43,6 +48,15 @@ jobs:\n name: windows-artifacts\n path: artifacts\n windows-test:\n+ if: >-\n+ ${{\n+ (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n+ github.ref == 'refs/heads/maint' ||\n+ github.ref == 'refs/heads/master' ||\n+ github.ref == 'refs/heads/next' ||\n+ github.ref == 'refs/heads/jch' ||\n+ github.ref == 'refs/heads/pu'\n+ }}\n runs-on: windows-latest\n needs: [windows-build]\n strategy:\n@@ -82,6 +96,15 @@ jobs:\n name: failed-tests-windows\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n vs-build:\n+ if: >-\n+ ${{\n+ (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n+ github.ref == 'refs/heads/maint' ||\n+ github.ref == 'refs/heads/master' ||\n+ github.ref == 'refs/heads/next' ||\n+ github.ref == 'refs/heads/jch' ||\n+ github.ref == 'refs/heads/pu'\n+ }}\n env:\n MSYSTEM: MINGW64\n NO_PERL: 1\n@@ -130,6 +153,15 @@ jobs:\n name: vs-artifacts\n path: artifacts\n vs-test:\n+ if: >-\n+ ${{\n+ (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n+ github.ref == 'refs/heads/maint' ||\n+ github.ref == 'refs/heads/master' ||\n+ github.ref == 'refs/heads/next' ||\n+ github.ref == 'refs/heads/jch' ||\n+ github.ref == 'refs/heads/pu'\n+ }}\n runs-on: windows-latest\n needs: [vs-build]\n strategy:\n@@ -166,6 +198,15 @@ jobs:\n ${{matrix.nr}} 10 t[0-9]*.sh)\n \"@\n regular:\n+ if: >-\n+ ${{\n+ (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n+ github.ref == 'refs/heads/maint' ||\n+ github.ref == 'refs/heads/master' ||\n+ github.ref == 'refs/heads/next' ||\n+ github.ref == 'refs/heads/jch' ||\n+ github.ref == 'refs/heads/pu'\n+ }}\n strategy:\n matrix:\n vector:\n@@ -201,6 +242,15 @@ jobs:\n name: failed-tests-${{matrix.vector.jobname}}\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n dockerized:\n+ if: >-\n+ ${{\n+ (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n+ github.ref == 'refs/heads/maint' ||\n+ github.ref == 'refs/heads/master' ||\n+ github.ref == 'refs/heads/next' ||\n+ github.ref == 'refs/heads/jch' ||\n+ github.ref == 'refs/heads/pu'\n+ }}\n strategy:\n matrix:\n vector:\n@@ -225,6 +275,15 @@ jobs:\n name: failed-tests-${{matrix.vector.jobname}}\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n static-analysis:\n+ if: >-\n+ ${{\n+ (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n+ github.ref == 'refs/heads/maint' ||\n+ github.ref == 'refs/heads/master' ||\n+ github.ref == 'refs/heads/next' ||\n+ github.ref == 'refs/heads/jch' ||\n+ github.ref == 'refs/heads/pu'\n+ }}\n env:\n jobname: StaticAnalysis\n runs-on: ubuntu-latest\n@@ -233,6 +292,15 @@ jobs:\n - run: ci/install-dependencies.sh\n - run: ci/run-static-analysis.sh\n documentation:\n+ if: >-\n+ ${{\n+ (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n+ github.ref == 'refs/heads/maint' ||\n+ github.ref == 'refs/heads/master' ||\n+ github.ref == 'refs/heads/next' ||\n+ github.ref == 'refs/heads/jch' ||\n+ github.ref == 'refs/heads/pu'\n+ }}\n env:\n jobname: Documentation\n runs-on: ubuntu-latest\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex e516b080df..a2e6a3d2ca 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -79,8 +79,8 @@ test your changes on Linux, Mac (and hopefully soon Windows). See\n GitHub-Travis CI hints section for details.\n \n Alternately, you can use GitHub Actions (which supports testing your changes\n-on Linux, macOS, and Windows) by pushing into a branch whose name starts\n-with \"for-ci\", or a tag whose name doesn't have `wip`,\n+on Linux, macOS, and Windows) by pushing into a branch or tag\n+whose name doesn't have `wip`,\n or opening a GitHub's Pull Request against\n https://github.com/git/git.git or a fork of that repository.\n \n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"397115","messageId":"20200505164326.GA64077@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200505002055.GC64230@syl.local","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T16:43:26Z","receivedAt":"2020-05-05T16:43:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 04, 2020 at 06:20:55PM -0600, Taylor Blau wrote:\n\n> > > Of course, I don't want to maintain a one-patch difference between\n> > > ttaylorr/git@master and git/git@master, so I wonder if we could get a\n> > > little more creative with these rules and actually run Actions on\n> > > *every* branch, but introduce a new first step which stops the rest of\n> > > the actions run (so that in practice we're not running CI on\n> > > non-integration branches in Junio's tree).\n> >\n> > I don't understand what that would accomplish. If we ran the actions on\n> > every branch but stopped the run, then you wouldn't get the CI results\n> > you want. What am I missing?\n> \n> That on forks of git/git we *would't* stop the run for non-integration\n> branches, i.e., that we'd have something like:\n\nAh, so the first step is \"if we are gitster/git, then do not run\", not\n\"do not run\".\n\nBut that is missing the point of the exercise, no? The question of what\ngitster/git should do was a side conversation. The purpose of Dscho's\noriginal patch and Danh's followup was to allow anybody to choose which\nbranches in their own fork. I.e.:\n\n> * Actions is running on all branches, of all forks, all the time.\n\nThis is how it works now, and is the exact thing we are trying to fix.\n\n-Peff\n"},{"id":"397116","messageId":"20200505164740.GB64077@coredump.intra.peff.net","threadId":"53374","inReplyTo":"48752d8b164bc0b11f4d82016415811a0b2bf08b.1588695295.git.congdanhqx@gmail.com","subject":"Re: [PATCH v3 1/3] SubmittingPatches: advertise GitHub Actions CI","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T16:47:40Z","receivedAt":"2020-05-05T16:47:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2020 at 11:26:39PM +0700, Đoàn Trần Công Danh wrote:\n\n> From 889cacb689 (ci: configure GitHub Actions for CI/PR, 2020-04-11),\n> GitHub Actions was introduced as an alternative CI system for Git\n> project.\n> \n> Let's advertise it to Git's contributors to help them test Git on\n> various platforms before submitting to Git.\n\nI think this makes sense. Two things:\n\n> +Alternately, you can use GitHub Actions (which supports testing your changes\n> +on Linux, macOS, and Windows) by pushing into a branch in your fork\n> +or opening a GitHub's Pull Request against\n> +https://github.com/git/git.git or a fork of that repository.\n\nProbably \"GitHub Pull Request\" would be more idiomatic English.\n\nDo people need to enable Actions on their forks for the branch push to\nwork? I didn't need to for my fork of git/git, but I'm not sure if that's\nbecause I was playing with Actions months ago and forgot, or if having\nactions enabled on the parent repo makes it work.\n\nWhen I made a new repository that was not connected, I had to explicitly\nenable Actions on the site before it would run the workflow file.\n\n-Peff\n"},{"id":"397117","messageId":"20200505165125.GC64077@coredump.intra.peff.net","threadId":"53374","inReplyTo":"a4c6f687c0a8ce55863a19a1c4048438f02803b5.1588695295.git.congdanhqx@gmail.com","subject":"Re: [PATCH v3 2/3] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T16:51:25Z","receivedAt":"2020-05-05T16:51:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2020 at 11:26:40PM +0700, Đoàn Trần Công Danh wrote:\n\n> -on: [push, pull_request]\n> +on:\n> + pull_request:\n> + push:\n> + branches:\n> + - maint\n> + - master\n> + - next\n> + - jch\n> + - pu\n> + - 'for-ci**'\n\nShould this be \"for-ci/**\", or are we intending for \"for-ci-foo\" to\nwork? I'd suspect anybody who uses this would use a full directory\nnamespace in a refspec (like \"refs/heads/*:refs/heads/for-ci/*\"). It\nmight be simpler conceptually to only support that.\n\n> + tags:\n> + - '**'\n> + - '!**wip**'\n\nIMHO this \"wip\" match is going too far. That was the name in the example\nI used, but really it could have been anything. I think we should\neither:\n\n - just build all tags; it usually takes special effort to push them up\n anyway, so a one-off \"just mark this spot\" tag likely wouldn't get\n pushed anyway\n\n - just build v[0-9]*, which would catch actual releases\n\n-Peff\n"},{"id":"397118","messageId":"20200505165933.GC927@danh.dev","threadId":"53374","inReplyTo":"20200505164740.GB64077@coredump.intra.peff.net","subject":"Re: [PATCH v3 1/3] SubmittingPatches: advertise GitHub Actions CI","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-05T16:59:33Z","receivedAt":"2020-05-05T16:59:39Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-05 12:47:40-0400, Jeff King wrote:\n> On Tue, May 05, 2020 at 11:26:39PM +0700, Đoàn Trần Công Danh wrote:\n> \n> > From 889cacb689 (ci: configure GitHub Actions for CI/PR, 2020-04-11),\n> > GitHub Actions was introduced as an alternative CI system for Git\n> > project.\n> > \n> > Let's advertise it to Git's contributors to help them test Git on\n> > various platforms before submitting to Git.\n> \n> I think this makes sense. Two things:\n> \n> > +Alternately, you can use GitHub Actions (which supports testing your changes\n> > +on Linux, macOS, and Windows) by pushing into a branch in your fork\n> > +or opening a GitHub's Pull Request against\n> > +https://github.com/git/git.git or a fork of that repository.\n> \n> Probably \"GitHub Pull Request\" would be more idiomatic English.\n\nI guess you're right.\n\nWell, I'm not native English speaker.\nI was thinking, this kind of Pull Request is specific to GitHub,\nand it's different from git-request-pull(1), So, I use \"'s\" :)\n\n> Do people need to enable Actions on their forks for the branch push to\n> work? I didn't need to for my fork of git/git, but I'm not sure if that's\n> because I was playing with Actions months ago and forgot, or if having\n> actions enabled on the parent repo makes it work.\n\nIt's a long time from the first time I tinker with GitHub Actions,\nI couldn't recall if I need to enable it explicitly.\n\nI look into GitHub support pages[1] and GitHub tells me that\nGitHub Actions is enabled by default for everyone, and every repo.\nWe need to disable GitHub Actions explicitly, if we don't want it.\n\n\n> When I made a new repository that was not connected, I had to explicitly\n> enable Actions on the site before it would run the workflow file.\n\nIt seems like GitHub Actions will be triggered automatically if GitHub\nfinds any files in \"$TOPDIR/.github/workflows/*.yml\"\n\n[1]: https://help.github.com/en/actions/getting-started-with-github-actions/about-github-actions#disabling-or-limiting-github-actions-for-your-repository-or-organization\n\n-- \nDanh\n"},{"id":"397119","messageId":"20200505170104.GD64077@coredump.intra.peff.net","threadId":"53374","inReplyTo":"cover.1588695295.git.congdanhqx@gmail.com","subject":"Re: [PATCH v3 0/3] Provide option to opt in/out GitHub Actions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T17:01:04Z","receivedAt":"2020-05-05T17:01:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2020 at 11:26:38PM +0700, Đoàn Trần Công Danh wrote:\n\n> It seems like there're 2 schools for GitHub Actions,\n> - Opt-in by using some specific patterns\n> - Opt-out by using some specific patterns\n> \n> I tried to help everyone happy, but with my current knowledge, I couldn't.\n\nYeah, I agree it's not possible to make anyone happy.\n\nI think the special handling of git/git and gitster/git in patch 3 is\nnot worth doing. That case is already easy to solve because it's two\nrepos: just turn off Actions in gitster/git if Junio isn't looking at\nthe results, and leave them on in git/git.\n\nThe real problem we're trying to solve is people with forks who might\nwant some branches with CI, but not others. Right now the only solution\nis for them to make a separate repository, and push to both.\n\nTo do that we need some way of getting per-branch information into the\nActions workflow. The ideal solution would just pull extra data from\nsome other ref or config within the repository, but there doesn't seem\nto be a way to do that.\n\nSo we're left with:\n\n - changing the tree of the branch; this is painful to manage, and the\n tree changes risk leaking out when we send out patches, etc. I think\n we all agree this is too horrible.\n\n - annotating the commit message with [skip ci] or similar. This is\n less painful, but still risks leaking out during patch mailing, etc.\n\n - sticking data in the branch name. This is the \"for-ci\" thing, which\n requires you to opt-in to CI. But it could be -wip or -no-ci or\n whatever, which would flip the default.\n\nThe third one seems like the only workable thing, so we have to pick a\ndirection. I prefer \"for-ci\" to \"no-ci\" because it's easier to add a\nrefspec to push to for-ci/* than it is to remember to put \"no-ci\" in\nevery branch name that you _don't_ want built.\n\n-Peff\n"},{"id":"397120","messageId":"20200505170546.GD927@danh.dev","threadId":"53374","inReplyTo":"20200505165125.GC64077@coredump.intra.peff.net","subject":"Re: [PATCH v3 2/3] CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-05T17:05:46Z","receivedAt":"2020-05-05T17:05:52Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-05 12:51:25-0400, Jeff King wrote:\n> On Tue, May 05, 2020 at 11:26:40PM +0700, Đoàn Trần Công Danh wrote:\n> \n> > -on: [push, pull_request]\n> > +on:\n> > + pull_request:\n> > + push:\n> > + branches:\n> > + - maint\n> > + - master\n> > + - next\n> > + - jch\n> > + - pu\n> > + - 'for-ci**'\n> \n> Should this be \"for-ci/**\", or are we intending for \"for-ci-foo\" to\n> work? I'd suspect anybody who uses this would use a full directory\n> namespace in a refspec (like \"refs/heads/*:refs/heads/for-ci/*\"). It\n> might be simpler conceptually to only support that.\n\nI made this because I saw someone mentioned that they would like to\npush to 'for-ci' and expect it works for them.\n\nI guess it may be better to have:\n\n\t- for-ci\n\t- for-ci/**\n\n> \n> > + tags:\n> > + - '**'\n> > + - '!**wip**'\n> \n> IMHO this \"wip\" match is going too far. That was the name in the example\n> I used, but really it could have been anything. I think we should\n> either:\n> \n> - just build all tags; it usually takes special effort to push them up\n> anyway, so a one-off \"just mark this spot\" tag likely wouldn't get\n> pushed anyway\n> \n> - just build v[0-9]*, which would catch actual releases\n\nThis sounds better, just build \"v[0-9]*\" and ignore everything else,\nwith this pattern, I think we don't need to advertise tag to our\nusers. And our maintainer shouldn't worry about it, since our\nmaintainer will (likely) only push v[0-9]* tagged code, anyway.\n\n-- \nDanh\n"},{"id":"397121","messageId":"20200505170737.GE64077@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200505165933.GC927@danh.dev","subject":"Re: [PATCH v3 1/3] SubmittingPatches: advertise GitHub Actions CI","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T17:07:37Z","receivedAt":"2020-05-05T17:07:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2020 at 11:59:33PM +0700, Đoàn Trần Công Danh wrote:\n\n> > > +Alternately, you can use GitHub Actions (which supports testing your changes\n> > > +on Linux, macOS, and Windows) by pushing into a branch in your fork\n> > > +or opening a GitHub's Pull Request against\n> > > +https://github.com/git/git.git or a fork of that repository.\n> > \n> > Probably \"GitHub Pull Request\" would be more idiomatic English.\n> \n> I guess you're right.\n> \n> Well, I'm not native English speaker.\n> I was thinking, this kind of Pull Request is specific to GitHub,\n> and it's different from git-request-pull(1), So, I use \"'s\" :)\n\nUsing the possessive \"'s\" would imply you're talking about GitHub's\nfeature itself. But you're talking about \"a\" pull request, so I think\nyou want to just GitHub as an adjective, which would not generally be\npossessive. English is quirky. :)\n\n> > When I made a new repository that was not connected, I had to explicitly\n> > enable Actions on the site before it would run the workflow file.\n> \n> It seems like GitHub Actions will be triggered automatically if GitHub\n> finds any files in \"$TOPDIR/.github/workflows/*.yml\"\n\nIt definitely wasn't for me. Try creating a new repo and going to the\n\"Actions\" tab. I get a \"Get Started with GitHub Actions\" page. If I push\nup a copy of git.git's master, then I get \"Workflows aren't being run in\nthis repository\" with a big green button to enable.\n\nI'm just not sure if that happens for people who fork git/git instead of\nmaking a new repo. I'm reluctant to delete and remake my fork, but I\nguess it wouldn't be too hard to re-create.\n\nI think it's OK to leave it out for now. Even if this is how it works\nfor a fork, it's not hard to discover what to do if you click the\nActions tab.\n\n-Peff\n"},{"id":"397122","messageId":"20200505171108.GF64077@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200505170546.GD927@danh.dev","subject":"Re: [PATCH v3 2/3] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T17:11:08Z","receivedAt":"2020-05-05T17:11:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 06, 2020 at 12:05:46AM +0700, Đoàn Trần Công Danh wrote:\n\n> > Should this be \"for-ci/**\", or are we intending for \"for-ci-foo\" to\n> > work? I'd suspect anybody who uses this would use a full directory\n> > namespace in a refspec (like \"refs/heads/*:refs/heads/for-ci/*\"). It\n> > might be simpler conceptually to only support that.\n> \n> I made this because I saw someone mentioned that they would like to\n> push to 'for-ci' and expect it works for them.\n> \n> I guess it may be better to have:\n> \n> \t- for-ci\n> \t- for-ci/**\n\nAh, that makes sense.\n\nYeah, the double-rule looks fine to me, but understanding that use, the\noriginal \"for-ci**\" is OK to me, too.\n\n-Peff\n"},{"id":"397123","messageId":"xmqqo8r2b6y4.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200505164326.GA64077@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-05T17:57:39Z","receivedAt":"2020-05-05T17:57:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> But that is missing the point of the exercise, no? The question of what\n> gitster/git should do was a side conversation. The purpose of Dscho's\n> original patch and Danh's followup was to allow anybody to choose which\n> branches in their own fork. I.e.:\n>\n>> * Actions is running on all branches, of all forks, all the time.\n>\n> This is how it works now, and is the exact thing we are trying to fix.\n\nThanks for clarifying and refocusing the discussion. I am onboard.\n\nIt seems to me that there are only two and half approaches, then:\n\n - Branch-build is opt-in; only branches that match selected, known,\n and fixed patterns will be built (e.g. 'maint', 'maint-*',\n 'master', 'next', 'pu', and 'for-ci/*').\n\n - Branch-build is opt-out; branches that match selected, known, and\n fixed patterns will be excluded (e.g., '*-wip').\n\n - If you do not want your branches want to be skipped, you need to\n tweak the commit at the tip (e.g. mark with '[skip ci]' log\n message, munging .github/workflows/ in the tree).\n\nThe last one is only there for completeness. I do not think mucking\nwith the objects recorded in the history, whether it is a tweaked\nlog message or tweaked tree contents, is a good way to do this.\n\nMore random ideas...\n\nWould it be too much hassle to use notes for a thing like this?\nPerhaps push out with refs/notes/skip-ci note attached to a commit\nyou do not want to be built? I have a feeling that it gives way\noverkill flexibility with little gain (probably too cumbersome to\nmanage).\n\nDoes push into GitHub repository offer an ability to pass arbitrary\npush option, to which actions that trigger \"on: push\" event can\nreact?\n\n"},{"id":"397126","messageId":"20200505182418.GA66702@coredump.intra.peff.net","threadId":"53374","inReplyTo":"xmqqo8r2b6y4.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T18:24:18Z","receivedAt":"2020-05-05T18:24:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2020 at 10:57:39AM -0700, Junio C Hamano wrote:\n\n> Would it be too much hassle to use notes for a thing like this?\n> Perhaps push out with refs/notes/skip-ci note attached to a commit\n> you do not want to be built? I have a feeling that it gives way\n> overkill flexibility with little gain (probably too cumbersome to\n> manage).\n\nI think using notes would be a hassle. This config is really associated\nwith a branch, not a particular config (so you'd have to make sure they\npropagate across rebases, etc).\n\nBut _if_ we can read from other refs in the repository, I would be very\nhappy if we parsed config out of refs/ci/branches or something. It feels\nlike that's something that ought to be possible, but I haven't quite\nfigured out a way to do it.\n\nReally all we want is some kind of per-repo variable storage where the\nvalues aren't baked into the tree. There is a \"secrets\" system that can\nbe used for this, though it kind of feels like an abuse of the concept.\n\n> Does push into GitHub repository offer an ability to pass arbitrary\n> push option, to which actions that trigger \"on: push\" event can\n> react?\n\nNo, I don't think so.\n\n-Peff\n"},{"id":"397130","messageId":"xmqq4ksub4k8.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"a4c6f687c0a8ce55863a19a1c4048438f02803b5.1588695295.git.congdanhqx@gmail.com","subject":"Re: [PATCH v3 2/3] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-05T18:49:11Z","receivedAt":"2020-05-05T18:49:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Đoàn Trần Công Danh writes:\n\n> Git's maintainer usually don't have enough time to debug the failure of\n> invidual feature branch, they usually want to look at intergration\n> branches only.\n\nPlease please please do not make this thing about me. I do not have\nActions enabled at https://github.com/gitster/git/ repository anyway.\n\nInstead, please focus on making the end result useful for general\ncontributors.\n\n> Contributors now can have GitHub Actions as an opt-in option,\n> should they want to check their code, they will push into designated\n> branch.\n\nOK, so this is an opt-in approach as you outlined in the cover\nletter.\n\n> + pull_request:\n> + push:\n> + branches:\n> + - maint\n> + - master\n> + - next\n> + - jch\n> + - pu\n> + - 'for-ci**'\n> + tags:\n> + - '**'\n> + - '!**wip**'\n\nI agree with the agreement you and Peff reached about for-ci plus\nfor-ci/** patterns and building only v[0-9] tags in your discussion\ndownthread.\n\nThaks.\n"},{"id":"397131","messageId":"xmqqzham9piy.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"a2e548b683cd584fd686a44e1d7f3473943fc73f.1588695295.git.congdanhqx@gmail.com","subject":"Re: [PATCH v3 3/3] fixup! CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-05T18:59:17Z","receivedAt":"2020-05-05T18:59:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Đoàn Trần Công Danh writes:\n\n> Should we want to enable GitHub Action for all repo-s, except git/git\n> and gitster/git. We'll want to have this patch fix-up to the previous\n> one.\n\nJust to get everybody on the same page,\n\n\tgit/git has only the primary integration branches and tags\n\tgitster/git has broken out individual topics\n\nWe do want to build everything in git/git repository.\n\nI do not have Actions enabled for gitster/git repository.\n\nI expect general contributors to fork from the former, push their\nwork on their own branches (not the copies of the public integration\nbranches like 'master', 'next', etc.) so that they can throw a pull\nrequest at git/git.\n\n> jobs:\n> windows-build:\n> + if: >-\n> + ${{\n> + (github.repository_owner != 'git' && github.repository_owner != 'gitster') ||\n> + github.ref == 'refs/heads/maint' ||\n> + github.ref == 'refs/heads/master' ||\n> + github.ref == 'refs/heads/next' ||\n> + github.ref == 'refs/heads/jch' ||\n> + github.ref == 'refs/heads/pu'\n> + }}\n\nIalready asked not to make this about me. You do not want to search\nand replace 'gitster' with 'peff' or 'dscho' or whatever string,\nonly because/when I chose to retire. Such an occasion shouldn't be\na significant event to the project's codebase.\n\nThanks.\n\n\n"},{"id":"397136","messageId":"20200505210451.GA645290@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200505182418.GA66702@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T21:04:51Z","receivedAt":"2020-05-05T21:04:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2020 at 02:24:18PM -0400, Jeff King wrote:\n\n> But _if_ we can read from other refs in the repository, I would be very\n> happy if we parsed config out of refs/ci/branches or something. It feels\n> like that's something that ought to be possible, but I haven't quite\n> figured out a way to do it.\n\nOK, I finally figured this out. The result is the patch below, which I\nthink should make everybody happy. Or at least has the ability to do so\nif they're willing to push a config ref. ;)\n\n-- >8 --\nSubject: [PATCH] ci: allow per-branch config for GitHub Actions\n\nDepending on the workflows of individual developers, it can either be\nconvenient or annoying that our GitHub Actions CI jobs are run on every\nbranch. As an example of annoying: if you carry many half-finished\nwork-in-progress branches and rebase them frequently against master,\nyou'd get tons of failure reports that aren't interesting (not to\nmention the wasted CPU).\n\nThis commit adds a new job which checks a special ref within the\nrepository for CI config, and (optionally) causes all of the other jobs\nto be skipped.\n\nThere have been a few alternatives discussed:\n\nOne option is to carry information in the commit itself about whether it\nshould be tested, either in the tree itself (changing the workflow YAML\nfile) or in the commit message (a \"[skip ci]\" flag or similar). But\nthese are frustrating and error-prone to use:\n\n - you have to manually apply them to each branch that you want to mark\n\n - it's easy for them to leak into other workflows, like emailing patches\n\nWe could likewise try to get some information from the branch name. But\nthat leads to debates about whether the default should be \"off\" or \"on\",\nand overriding still ends up somewhat awkward. If we default to \"on\",\nyou have to remember to name your branches appropriately to skip CI. And\nif \"off\", you end up having to contort your branch names or duplicate\nyour pushes with an extra refspec.\n\nBy comparison, this commit's solution lets you specify your config once\nand forget about it, and all of the data is off in its own ref, where it\ncan be changed by individual forks without touching the main tree.\n\nI used refs/ci/config as the config ref, which should be a commit whose\ntree contains various config files (right now the only one is\n\"ref-whitelist\"). It was intentional to avoid refs/heads/ here so we\ndon't conflict with any branch workflows. But it does make it a little\nawkward to edit, since you can't check it out directly.\n\nRight now the logic is to run CI for all branches by default, unless a\nwhitelist exists, in which case the branch must be mentioned there\n(using its fully qualified ref name). We could easily add in a\nblacklist, as well. Or since we're running a shell in a VM, we really\ncould just run \"./allow-ref $refname\" and let individual forks specify\nwhatever shell code they like.\n\nSigned-off-by: Jeff King \n---\nAfter writing that, I think we probably ought to just do the allow-ref\nthing from the start, and skip this whitelist logic. Then we should\nnever need to change this workflow file again. People can implement\nwhatever weird custom logic they want to.\n\n .github/workflows/main.yml | 32 ++++++++++++++++++++++++++++++++\n 1 file changed, 32 insertions(+)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex fd4df939b5..51f4ff6e89 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -6,7 +6,29 @@ env:\n DEVELOPER: 1\n \n jobs:\n+ check-ci:\n+ runs-on: ubuntu-latest\n+ outputs:\n+ enabled: ${{ steps.check-ref.outputs.enabled }}\n+ steps:\n+ - uses: actions/checkout@v2\n+ continue-on-error: true\n+ with:\n+ ref: refs/ci/config\n+ - id: check-ref\n+ name: check whether CI is enabled for ref\n+ run: |\n+ enabled=yes\n+ if test -e ref-whitelist &&\n+ ! grep '^${{ github.ref }}$' ref-whitelist\n+ then\n+ enabled=no\n+ fi\n+ echo \"::set-output name=enabled::$enabled\"\n+\n windows-build:\n+ needs: check-ci\n+ if: needs.check-ci.outputs.enabled == 'yes'\n runs-on: windows-latest\n steps:\n - uses: actions/checkout@v1\n@@ -70,6 +92,8 @@ jobs:\n name: failed-tests-windows\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n vs-build:\n+ needs: check-ci\n+ if: needs.check-ci.outputs.enabled == 'yes'\n env:\n MSYSTEM: MINGW64\n NO_PERL: 1\n@@ -154,6 +178,8 @@ jobs:\n ${{matrix.nr}} 10 t[0-9]*.sh)\n \"@\n regular:\n+ needs: check-ci\n+ if: needs.check-ci.outputs.enabled == 'yes'\n strategy:\n matrix:\n vector:\n@@ -189,6 +215,8 @@ jobs:\n name: failed-tests-${{matrix.vector.jobname}}\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n dockerized:\n+ needs: check-ci\n+ if: needs.check-ci.outputs.enabled == 'yes'\n strategy:\n matrix:\n vector:\n@@ -213,6 +241,8 @@ jobs:\n name: failed-tests-${{matrix.vector.jobname}}\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n static-analysis:\n+ needs: check-ci\n+ if: needs.check-ci.outputs.enabled == 'yes'\n env:\n jobname: StaticAnalysis\n runs-on: ubuntu-latest\n@@ -221,6 +251,8 @@ jobs:\n - run: ci/install-dependencies.sh\n - run: ci/run-static-analysis.sh\n documentation:\n+ needs: check-ci\n+ if: needs.check-ci.outputs.enabled == 'yes'\n env:\n jobname: Documentation\n runs-on: ubuntu-latest\n-- \n2.26.2.962.g87ee755179\n\n"},{"id":"397138","messageId":"xmqqlfm69il6.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200505210451.GA645290@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-05T21:29:09Z","receivedAt":"2020-05-05T21:29:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, May 05, 2020 at 02:24:18PM -0400, Jeff King wrote:\n>\n>> But _if_ we can read from other refs in the repository, I would be very\n>> happy if we parsed config out of refs/ci/branches or something. It feels\n>> like that's something that ought to be possible, but I haven't quite\n>> figured out a way to do it.\n>\n> OK, I finally figured this out. The result is the patch below, which I\n> think should make everybody happy. Or at least has the ability to do so\n> if they're willing to push a config ref. ;)\n\nThat sounds good.\n\n> Subject: [PATCH] ci: allow per-branch config for GitHub Actions\n>\n> Depending on the workflows of individual developers, it can either be\n> convenient or annoying that our GitHub Actions CI jobs are run on every\n> branch. As an example of annoying: if you carry many half-finished\n> work-in-progress branches and rebase them frequently against master,\n> you'd get tons of failure reports that aren't interesting (not to\n> mention the wasted CPU).\n\nOK.\n\n> This commit adds a new job which checks a special ref within the\n> repository for CI config, and (optionally) causes all of the other jobs\n> to be skipped.\n\nNice---that way, all existing jobs do not even need to know about\nthe special controlling ref.\n\n> Right now the logic is to run CI for all branches by default, unless a\n> whitelist exists, in which case the branch must be mentioned there\n> (using its fully qualified ref name).\n\nSo there is no wildcard? Not really complaining, but am wondering.\n\n> We could easily add in a\n> blacklist, as well.\n\nOK.\n\n> Or since we're running a shell in a VM, we really\n> could just run \"./allow-ref $refname\" and let individual forks specify\n> whatever shell code they like.\n\nI presume that you are saying \"checking out the tree of refs/ci/config\nand there is a program allow-ref that can tell which one to run ci on\"?\n\n> After writing that, I think we probably ought to just do the allow-ref\n> thing from the start, and skip this whitelist logic. Then we should\n> never need to change this workflow file again. People can implement\n> whatever weird custom logic they want to.\n\nProbably.\n\n> jobs:\n> + check-ci:\n> + runs-on: ubuntu-latest\n> + outputs:\n> + enabled: ${{ steps.check-ref.outputs.enabled }}\n> + steps:\n> + - uses: actions/checkout@v2\n> + continue-on-error: true\n> + with:\n> + ref: refs/ci/config\n> + - id: check-ref\n> + name: check whether CI is enabled for ref\n> + run: |\n> + enabled=yes\n> + if test -e ref-whitelist &&\n> + ! grep '^${{ github.ref }}$' ref-whitelist\n> + then\n> + enabled=no\n> + fi\n> + echo \"::set-output name=enabled::$enabled\"\n> +\n> windows-build:\n> + needs: check-ci\n> + if: needs.check-ci.outputs.enabled == 'yes'\n> runs-on: windows-latest\n> steps:\n> - uses: actions/checkout@v1\n\nOh, quite nice. Simple and clean.\n\n"},{"id":"397140","messageId":"20200505215843.GA646020@coredump.intra.peff.net","threadId":"53374","inReplyTo":"xmqqlfm69il6.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-05T21:58:43Z","receivedAt":"2020-05-05T21:58:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2020 at 02:29:09PM -0700, Junio C Hamano wrote:\n\n> > This commit adds a new job which checks a special ref within the\n> > repository for CI config, and (optionally) causes all of the other jobs\n> > to be skipped.\n> \n> Nice---that way, all existing jobs do not even need to know about\n> the special controlling ref.\n\nYep. Also, it only has to run once. It's not too expensive, but it does\nseem to take a few seconds to run.\n\nI think the VM setup is usually pretty quick due to the way Actions is\nimplemented. I made sure we avoid cloning the whole normal git.git tree,\nbut we still have to clone the individual config branch. It seems to\ntake ~3-5s to run that job. I'd have liked to make it even cheaper for\nbranches which don't want CI (less for latency, but more just because I\nhate to waste GitHub's resources), but I think that's the best we can\ndo. And for cases where we actually run CI, 3s is a drop in the bucket. ;)\n\n> > Right now the logic is to run CI for all branches by default, unless a\n> > whitelist exists, in which case the branch must be mentioned there\n> > (using its fully qualified ref name).\n> \n> So there is no wildcard? Not really complaining, but am wondering.\n\nCorrect, there's no wildcard. It would be easy to add one, now that this\ngets us to a working shell environment with the refname available. And\nprobably worth doing if we don't just go the \"execute a program from the\nconfig tree\" route.\n\n> > Or since we're running a shell in a VM, we really\n> > could just run \"./allow-ref $refname\" and let individual forks specify\n> > whatever shell code they like.\n> \n> I presume that you are saying \"checking out the tree of refs/ci/config\n> and there is a program allow-ref that can tell which one to run ci on\"?\n\nYes, exactly.\n\n-Peff\n"},{"id":"397142","messageId":"xmqqd07i9fut.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200505215843.GA646020@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-05T22:28:10Z","receivedAt":"2020-05-05T22:28:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> > Or since we're running a shell in a VM, we really\n>> > could just run \"./allow-ref $refname\" and let individual forks specify\n>> > whatever shell code they like.\n>> \n>> I presume that you are saying \"checking out the tree of refs/ci/config\n>> and there is a program allow-ref that can tell which one to run ci on\"?\n>\n> Yes, exactly.\n\nI guess a simple example implementation of allow-ref script, with a\nbit of instruction to tell people how to initialize a separate and\notherwise empty repository with just a (possibly customized) copy of\nthe script in it, and push its 'master' branch to refs/ci/config of\ntheir Git fork, would be a way to go, then?\n\nSounds simple enough. Cycles to spin up a VM that adds 3 seconds\nlatency, only to know that a branch won't need to be built, does\nsound like a bit unfortunate, though.\n"},{"id":"397161","messageId":"20200506004612.GE927@danh.dev","threadId":"53374","inReplyTo":"20200505210451.GA645290@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-06T00:46:12Z","receivedAt":"2020-05-06T00:46:18Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-05 17:04:51-0400, Jeff King wrote:\n> We could likewise try to get some information from the branch name. But\n> that leads to debates about whether the default should be \"off\" or \"on\",\n> and overriding still ends up somewhat awkward. If we default to \"on\",\n> you have to remember to name your branches appropriately to skip CI. And\n> if \"off\", you end up having to contort your branch names or duplicate\n> your pushes with an extra refspec.\n> \n> By comparison, this commit's solution lets you specify your config once\n> and forget about it, and all of the data is off in its own ref, where it\n> can be changed by individual forks without touching the main tree.\n\nHow about supports the best of both worlds.\n\nLet's say support wildcard 'wip/**' for opt-out.\nAnd use \"./allow-ref\" to filter everything that passed the wildcard.\n\n> I used refs/ci/config as the config ref, which should be a commit whose\n> tree contains various config files (right now the only one is\n> \"ref-whitelist\"). It was intentional to avoid refs/heads/ here so we\n> don't conflict with any branch workflows. But it does make it a little\n> awkward to edit, since you can't check it out directly.\n> \n> Right now the logic is to run CI for all branches by default, unless a\n> whitelist exists, in which case the branch must be mentioned there\n> (using its fully qualified ref name). We could easily add in a\n> blacklist, as well. Or since we're running a shell in a VM, we really\n> could just run \"./allow-ref $refname\" and let individual forks specify\n> whatever shell code they like.\n\nShould we go with this route, here is a fix-up patch for your,\n(after cherry-pick my [1/3])\n--------------------8<-------------------\nSubject: [PATCH] fixup! ci: allow per-branch config for GitHub Actions\n\nSigned-off-by: Đoàn Trần Công Danh \n---\n .github/workflows/main.yml | 3 +--\n Documentation/SubmittingPatches | 12 ++++++++++++\n contrib/ci-config-allow-ref | 9 +++++++++\n 3 files changed, 22 insertions(+), 2 deletions(-)\n create mode 100755 contrib/ci-config-allow-ref\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 51f4ff6e89..08217c5ed8 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -19,8 +19,7 @@ jobs:\n name: check whether CI is enabled for ref\n run: |\n enabled=yes\n- if test -e ref-whitelist &&\n- ! grep '^${{ github.ref }}$' ref-whitelist\n+ if test -x allow-ref && ! ./allow-ref '${{ github.ref }}'\n then\n enabled=no\n fi\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 8686318550..8175424929 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -82,6 +82,18 @@ Alternately, you can use GitHub Actions (which supports testing your changes\n on Linux, macOS, and Windows) by pushing into a branch in your fork\n or opening a GitHub's Pull Request against\n https://github.com/git/git.git or a fork of that repository.\n+In the event that you only want to trigger GitHub Actions for specific\n+refname, you can create an executable file named `allow-ref` in\n+`refs/ci/config`. Those below steps may help you:\n+--------------\n+$ git checkout --orphan ci-config\n+$ cp contrib/ci-config-allow-ref allow-ref\n+$ $EDITOR allow-ref\n+$ git rm -rf .\n+$ git commit allow-ref\n+$ git push HEAD:refs/ci/config\n+--------------\n+\n \n Do not forget to update the documentation to describe the updated\n behavior and make sure that the resulting documentation set formats\ndiff --git a/contrib/ci-config-allow-ref b/contrib/ci-config-allow-ref\nnew file mode 100755\nindex 0000000000..b53e9ddbd0\n--- /dev/null\n+++ b/contrib/ci-config-allow-ref\n@@ -0,0 +1,9 @@\n+#!/bin/sh\n+# Sample filter for GitHub Actions\n+# GitHub Actions will run if and only if this script exit with zero status\n+\n+REFNAME=\"$1\"\n+\n+case \"$REFNAME\" in\n+refs/heads/no-ci*) exit 1 ;;\n+esac\n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"397164","messageId":"xmqqr1vx90mt.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200506004612.GE927@danh.dev","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-06T03:56:58Z","receivedAt":"2020-05-06T03:57:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Đoàn Trần Công Danh writes:\n\n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index 8686318550..8175424929 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -82,6 +82,18 @@ Alternately, you can u\n> on Linux, macOS, and Windows) by pushing into a branch in your fork\n> or opening a GitHub's Pull Request against\n> https://github.com/git/git.git or a fork of that repository.\n> +In the event that you only want to trigger GitHub Actions for specific\n> +refname, you can create an executable file named `allow-ref` in\n> +`refs/ci/config`. Those below steps may help you:\n\n\"These steps below\" or \"The follwoing steps\", perhaps.\n\n> +--------------\n> +$ git checkout --orphan ci-config\n> +$ cp contrib/ci-config-allow-ref allow-ref\n> +$ $EDITOR allow-ref\n> +$ git rm -rf .\n\nThis sounds horrible. You just nuked the entire files in the\nworking tree you use for your everyday Git hacking to edit a\nsingle file.\n\n> +$ git commit allow-ref\n\nIf allow-ref were added to the index before this \"git commit\", the\nprevious \"git rm -rf .\" would have removed it. Since the surviving\nallow-ref file must have been untracked, this \"git commit\" would not\ncommit anything. Forgot to \"git add\"?\n\n> +$ git push HEAD:refs/ci/config\n> +--------------\n\n> Do not forget to update the documentation to describe the updated\n> behavior and make sure that the resulting documentation set formats\n> diff --git a/contrib/ci-config-allow-ref b/contrib/ci-config-allow-ref\n> new file mode 100755\n> index 0000000000..b53e9ddbd0\n> --- /dev/null\n> +++ b/contrib/ci-config-allow-ref\n> @@ -0,0 +1,9 @@\n> +#!/bin/sh\n> +# Sample filter for GitHub Actions\n> +# GitHub Actions will run if and only if this script exit with zero status\n\ns/exit/exits/;\n\nAs the instruction above says, we should set the example and\ndescribe the behaviour we implemented initially. Something as basic\nlike ...\n\n # Build any branch other than those whose name begins with \"no-ci\"\n\n> +\n> +REFNAME=\"$1\"\n> +\n> +case \"$REFNAME\" in\n> +refs/heads/no-ci*) exit 1 ;;\n> +esac\n\n"},{"id":"397187","messageId":"20200506142500.GA2429@danh.dev","threadId":"53374","inReplyTo":"xmqqr1vx90mt.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-06T14:25:00Z","receivedAt":"2020-05-06T14:25:06Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-05 20:56:58-0700, Junio C Hamano wrote:\n> Đoàn Trần Công Danh writes:\n> > +--------------\n> > +$ git checkout --orphan ci-config\n> > +$ cp contrib/ci-config-allow-ref allow-ref\n> > +$ $EDITOR allow-ref\n> > +$ git rm -rf .\n> \n> This sounds horrible. You just nuked the entire files in the\n> working tree you use for your everyday Git hacking to edit a\n> single file.\n\nIt isn't that horrible as it sounds. It only removes the files that are\ncurrently added in index, which is the same with tracked files in old\nbranch, and we can get it back by switching back to old branch.\n\nI decided to make an orphanage branch because I would like to save\ntime and network bandwidth for the \"check-ci\" jobs. Since GitHub will\nfetch only single branch in GitHub Actions:\n\n\t/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/ci/config:refs/ci/config\n\nI wonder whether the \"git rm -rf .\" makes that block sounds horrible?\nIf that is the case, we can use the experimental git-switch(1)\ninstead, it's doing more-or-less the same (or is it the same?) with\n\"git checkout --orphan\" and \"git rm -rf .\"\n\n-----------------\n$ cp contrib/ci-config-allow-ref.sample allow-ref\n$ git switch --orphan ci-config\n$ edit allow-ref\n$ git add allow-ref\n$ git commit\n-----------------\n\nNote: I changed `$EDITOR` to `edit` to match other example of `edit`.\n\n> As the instruction above says, we should set the example and\n> describe the behaviour we implemented initially. Something as basic\n> like ...\n> \n> # Build any branch other than those whose name begins with \"no-ci\"\n\nThat's definitely better.\nAnd I think we should add `.sample` suffix to this file, too\n\nIf all of that's sensible enough, here is the replacement fix-up patch.\n--------------------8<------------------\nSubject: [PATCH] fixup! ci: allow per-branch config for GitHub Actions\n\nSigned-off-by: Đoàn Trần Công Danh \n---\n .github/workflows/main.yml | 3 +--\n Documentation/SubmittingPatches | 12 ++++++++++++\n contrib/ci-config-allow-ref.sample | 12 ++++++++++++\n 3 files changed, 25 insertions(+), 2 deletions(-)\n create mode 100755 contrib/ci-config-allow-ref.sample\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex 51f4ff6e89..08217c5ed8 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -19,8 +19,7 @@ jobs:\n name: check whether CI is enabled for ref\n run: |\n enabled=yes\n- if test -e ref-whitelist &&\n- ! grep '^${{ github.ref }}$' ref-whitelist\n+ if test -x allow-ref && ! ./allow-ref '${{ github.ref }}'\n then\n enabled=no\n fi\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex b916f07f2c..bf06284f29 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -82,6 +82,18 @@ Alternately, you can use GitHub Actions (which supports testing your changes\n on Linux, macOS, and Windows) by pushing into a branch in your fork\n or opening a GitHub Pull Request against\n https://github.com/git/git.git or a fork of that repository.\n+In the event that you only want to trigger GitHub Actions for specific\n+refname, you can create an executable file named `allow-ref` in\n+`refs/ci/config`. The following steps may help you:\n+--------------\n+$ cp contrib/ci-config-allow-ref.sample allow-ref\n+$ git switch --orphan \n+$ edit allow-ref\n+$ git add allow-ref\n+$ git commit allow-ref\n+$ git push HEAD:refs/ci/config\n+--------------\n+\n \n Do not forget to update the documentation to describe the updated\n behavior and make sure that the resulting documentation set formats\ndiff --git a/contrib/ci-config-allow-ref.sample b/contrib/ci-config-allow-ref.sample\nnew file mode 100755\nindex 0000000000..1973e88912\n--- /dev/null\n+++ b/contrib/ci-config-allow-ref.sample\n@@ -0,0 +1,12 @@\n+#!/bin/sh\n+# Sample filter for GitHub Actions\n+# GitHub Actions will run if and only if this script exits with zero status\n+\n+# This sample filter will ask GitHub Actions to build\n+# any branches whose name doesn't start with \"no-ci\"\n+\n+REFNAME=\"$1\"\n+\n+case \"$REFNAME\" in\n+refs/heads/no-ci*) exit 1 ;;\n+esac\n-- \n2.26.2.672.g232c24e857\n\n"},{"id":"397189","messageId":"nycvar.QRO.7.76.6.2005061623520.56@tvgsbejvaqbjf.bet","threadId":"53374","inReplyTo":"xmqqlfm69il6.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-05-06T15:09:39Z","receivedAt":"2020-05-06T15:09:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 5 May 2020, Junio C Hamano wrote:\n\n> Jeff King writes:\n>\n> > jobs:\n> > + check-ci:\n> > + runs-on: ubuntu-latest\n> > + outputs:\n> > + enabled: ${{ steps.check-ref.outputs.enabled }}\n> > + steps:\n> > + - uses: actions/checkout@v2\n> > + continue-on-error: true\n> > + with:\n> > + ref: refs/ci/config\n> > + - id: check-ref\n> > + name: check whether CI is enabled for ref\n> > + run: |\n> > + enabled=yes\n> > + if test -e ref-whitelist &&\n> > + ! grep '^${{ github.ref }}$' ref-whitelist\n> > + then\n> > + enabled=no\n> > + fi\n> > + echo \"::set-output name=enabled::$enabled\"\n> > +\n> > windows-build:\n> > + needs: check-ci\n> > + if: needs.check-ci.outputs.enabled == 'yes'\n> > runs-on: windows-latest\n> > steps:\n> > - uses: actions/checkout@v1\n>\n> Oh, quite nice. Simple and clean.\n\nThe idea is indeed very neat. I think we can do a bit better with resource\nusage by not even bothering to check this branch out. Something along\nthose lines (sorry, I really would love to have the time to test this...):\n\n - id: check-ref\n name: check whether CI is enabled for ref\n uses: actions/github-script@0.9.0\n with:\n script: |\n const req = {\n owner: context.repo.owner,\n repo: context.repo.repo,\n ref: \"ci/config\"\n };\n\n try {\n req.tree_sha = (await github.git.getRef(req)).data.object.sha;\n (await github.git.getTree(req))\n .tree.filter(e => e.path == 'ref-whitelist').map(e => {\n req.file_sha = e.sha;\n });\n const list = Buffer.from((await github.git.getBlob(req)).data.content, 'base64').toString('UTF-8');\n core.setOutput('enabled', `\\n${list}`.indexOf(`\\n${{github.ref}}\\n`) < 0 ? 'no' : 'yes');\n } catch (e) {\n core.setOutput('enabled', 'yes');\n }\n\nCiao,\nDscho\n"},{"id":"397198","messageId":"xmqqeerx81wy.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"nycvar.QRO.7.76.6.2005061623520.56@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-06T16:26:53Z","receivedAt":"2020-05-06T16:27:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The idea is indeed very neat. I think we can do a bit better with resource\n> usage by not even bothering to check this branch out. Something along\n> those lines (sorry, I really would love to have the time to test this...):\n\nNice. I view the latest round of Peff's idea \"allow-ref\" as\n\"because we are spinning a VM anyway, why not just run an end-user\nsupplied script and let it decide?\" and not as \"we must have a\nTuring complete flexibility so let's run a script in a VM\". In\nother words, it may be overkill and we may strike a better tradeoff\nby living with reduced flexibility if there is a way to avoid the\nassociated cost.\n\nBut doesn't this (i.e. uses: actions/github-script) still pay the\ncost of spinning up a VM? How expensive is it to check out a small\ntree with a single file, whether it is ref-whitelist or allow-ref?\n\nIf the cost to check out a tree is dwarfed, it probably is not worth\npursuing the approach to use a canned \"don't customize, just use\"\nlogic in the workflow file to read a configuration file that can\nonly list full names of allowed refs.\n\nThanks.\n\n> - id: check-ref\n> name: check whether CI is enabled for ref\n> uses: actions/github-script@0.9.0\n> with:\n> script: |\n> const req = {\n> owner: context.repo.owner,\n> repo: context.repo.repo,\n> ref: \"ci/config\"\n> };\n>\n> try {\n> req.tree_sha = (await github.git.getRef(req)).data.object.sha;\n> (await github.git.getTree(req))\n> .tree.filter(e => e.path == 'ref-whitelist').map(e => {\n> req.file_sha = e.sha;\n> });\n> const list = Buffer.from((await github.git.getBlob(req)).data.content, 'base64').toString('UTF-8');\n> core.setOutput('enabled', `\\n${list}`.indexOf(`\\n${{github.ref}}\\n`) < 0 ? 'no' : 'yes');\n> } catch (e) {\n> core.setOutput('enabled', 'yes');\n> }\n>\n> Ciao,\n> Dscho\n"},{"id":"397201","messageId":"xmqqa72l81pe.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200506142500.GA2429@danh.dev","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-06T16:31:25Z","receivedAt":"2020-05-06T16:31:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Đoàn Trần Công Danh writes:\n\n> On 2020-05-05 20:56:58-0700, Junio C Hamano wrote:\n>> Đoàn Trần Công Danh writes:\n>> > +--------------\n>> > +$ git checkout --orphan ci-config\n>> > +$ cp contrib/ci-config-allow-ref allow-ref\n>> > +$ $EDITOR allow-ref\n>> > +$ git rm -rf .\n>> \n>> This sounds horrible. You just nuked the entire files in the\n>> working tree you use for your everyday Git hacking to edit a\n>> single file.\n>\n> It isn't that horrible as it sounds. It only removes the files that are\n> currently added in index, which is the same with tracked files in old\n> branch, and we can get it back by switching back to old branch.\n>\n> I decided to make an orphanage branch because I would like to save\n> time and network bandwidth for the \"check-ci\" jobs.\n\nI didn't say it is wrong to record a tree with a single file\n(allow-ref) in a commit that is pointed by the ci-config ref.\n\nI would have expected you to create such a commit in an otherwise\nempty repository, and push into your fork of Git at GitHub. That\nway, you won't have to checkout and/or refresh the index all of the\n3800+ files.\n\n> I wonder whether the \"git rm -rf .\" makes that block sounds horrible?\n> If that is the case, we can use the experimental git-switch(1)\n> instead, it's doing more-or-less the same (or is it the same?) with\n> \"git checkout --orphan\" and \"git rm -rf .\"\n\nThat does not change anything, as abuse of your primary repository\nis what offends me.\n"},{"id":"397286","messageId":"20200507120102.GB32465@danh.dev","threadId":"53374","inReplyTo":"nycvar.QRO.7.76.6.2005061623520.56@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-07T12:01:02Z","receivedAt":"2020-05-07T12:01:08Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-06 17:09:39+0200, Johannes Schindelin wrote:\n> The idea is indeed very neat. I think we can do a bit better with resource\n> usage by not even bothering to check this branch out. Something along\n> those lines (sorry, I really would love to have the time to test this...):\n\nWhile this can avoid the cost of checking out a whole branch (which\ncan be mitigated by using an orphan branch with single file),\n\nThis still spins up an VM, and actions/github-script run (I think)\nnodejs, which is more resource intensive than git and sh script.\nAbove statement maybe wrong, I'm not interacting much with nodejs.\n\n> - id: check-ref\n> name: check whether CI is enabled for ref\n> uses: actions/github-script@0.9.0\n> with:\n> script: |\n> const req = {\n> owner: context.repo.owner,\n> repo: context.repo.repo,\n> ref: \"ci/config\"\n> };\n> \n> try {\n> req.tree_sha = (await github.git.getRef(req)).data.object.sha;\n> (await github.git.getTree(req))\n> .tree.filter(e => e.path == 'ref-whitelist').map(e => {\n> req.file_sha = e.sha;\n> });\n> const list = Buffer.from((await github.git.getBlob(req)).data.content, 'base64').toString('UTF-8');\n> core.setOutput('enabled', `\\n${list}`.indexOf(`\\n${{github.ref}}\\n`) < 0 ? 'no' : 'yes');\n\nAnd this `indexOf` will check if our ref (exact) matchs (full line)\nwith some white-list list, which is very limited.\nSo people couldn't match by some pattern (grep can work).\n\nI haven't tested, but we may use part of above script to read a single\nfile from a ref, and add another steps for \"grep\"/\"sh\"\nI'm not sure if that script will cost more resources than git-checkout\nor not. And is that solutions over-engineered?\n\n-- \nDanh\n"},{"id":"397290","messageId":"20200507121727.GA3057274@coredump.intra.peff.net","threadId":"53374","inReplyTo":"xmqqeerx81wy.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-07T12:17:27Z","receivedAt":"2020-05-07T12:17:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 06, 2020 at 09:26:53AM -0700, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > The idea is indeed very neat. I think we can do a bit better with resource\n> > usage by not even bothering to check this branch out. Something along\n> > those lines (sorry, I really would love to have the time to test this...):\n> \n> Nice. I view the latest round of Peff's idea \"allow-ref\" as\n> \"because we are spinning a VM anyway, why not just run an end-user\n> supplied script and let it decide?\" and not as \"we must have a\n> Turing complete flexibility so let's run a script in a VM\". In\n> other words, it may be overkill and we may strike a better tradeoff\n> by living with reduced flexibility if there is a way to avoid the\n> associated cost.\n\nThe script is just javascript, which has an eval(). We could probably\nlet refs/ci/config:allow-ref be a snippet of javascript that we run.\n\nI do prefer the VM environment to snippets of javascript for a few\nreasons:\n\n - shell scripts match the rest of our Git toolbox (though that's a\n personal preference, and for the amount of code we're talking about\n even _I_ can do a little javascript)\n\n - it's easy to test your code locally by running \"./allow-ref foo\".\n Whereas emulating the environment in which those scriptlets are run\n is much trickier (e.g., you need a working github-api object)\n\nThat said, if this is more lightweight, I think it's worth exploring.\n\n> But doesn't this (i.e. uses: actions/github-script) still pay the\n> cost of spinning up a VM? How expensive is it to check out a small\n> tree with a single file, whether it is ref-whitelist or allow-ref?\n\nI suspect this script mechanism may be much cheaper. I don't know the\nimplementation details, but spinning up a nodejs container to run a\njavascript snippet should be much cheaper than a full ubuntu VM running\n\"git clone\" (the clone itself should be super cheap because it's a\nshallow single-branch clone of a tree with one file in it, but getting\nthere is relatively heavy-weight).\n\nBut I could be wrong. It's clear that they're not spinning up a full\nubuntu vm from scratch to serve the requests (since it happens in 3s).\nI'll see if I can get something working and do some timings.\n\nThe latency isn't incredibly important. This is all happening async, and\neither we'll skip CI (in which case you don't care how long it takes,\nsince you're not waiting on the result) or CI will take many minutes, in\nwhich case 3s is nothing. But I would like to be respectful of the CPU\nspent running Actions and be as lightweight as possible.\n\n-Peff\n"},{"id":"397291","messageId":"20200507122549.GB3057274@coredump.intra.peff.net","threadId":"53374","inReplyTo":"xmqqa72l81pe.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-07T12:25:49Z","receivedAt":"2020-05-07T12:25:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 06, 2020 at 09:31:25AM -0700, Junio C Hamano wrote:\n\n> Đoàn Trần Công Danh writes:\n> \n> > On 2020-05-05 20:56:58-0700, Junio C Hamano wrote:\n> >> Đoàn Trần Công Danh writes:\n> >> > +--------------\n> >> > +$ git checkout --orphan ci-config\n> >> > +$ cp contrib/ci-config-allow-ref allow-ref\n> >> > +$ $EDITOR allow-ref\n> >> > +$ git rm -rf .\n> >> \n> >> This sounds horrible. You just nuked the entire files in the\n> >> working tree you use for your everyday Git hacking to edit a\n> >> single file.\n> >\n> > It isn't that horrible as it sounds. It only removes the files that are\n> > currently added in index, which is the same with tracked files in old\n> > branch, and we can get it back by switching back to old branch.\n> >\n> > I decided to make an orphanage branch because I would like to save\n> > time and network bandwidth for the \"check-ci\" jobs.\n> \n> I didn't say it is wrong to record a tree with a single file\n> (allow-ref) in a commit that is pointed by the ci-config ref.\n> \n> I would have expected you to create such a commit in an otherwise\n> empty repository, and push into your fork of Git at GitHub. That\n> way, you won't have to checkout and/or refresh the index all of the\n> 3800+ files.\n\nYeah, I agree that all of the mechanisms for dealing with the unrelated\nhistory are somewhat awkward. Another issue is that you can't just:\n\n git clone --single-branch -b refs/ci/config my-config\n\nto work on it, because \"-b\" wants only heads or tags (we could address\nthat by putting it in refs/heads/ci-config or similar).\n\nIf we do go the javascript route, perhaps it would make sense for\nrefs/ci/config to be a single blob containing a snippet of javascript\nwith several functions. And then we could just eval() that and call the\nappropriate functions (if defined).\n\nThen a sample can live in the main repo with something like:\n\n # This file contains functions which will be run by the GitHub\n # Actions CI script.\n #\n # You may customize it for your own fork by modifying it on any branch\n # you like, and installing with:\n #\n # git push $(git rev-parse HEAD:ci/config):refs/ci/config\n #\n # [allow_ref() sample definition and documentation....]\n\nThat sidesteps most of those issues.\n\n-Peff\n"},{"id":"397293","messageId":"20200507124700.GA1378@danh.dev","threadId":"53374","inReplyTo":"20200507120102.GB32465@danh.dev","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-07T12:47:00Z","receivedAt":"2020-05-07T12:47:05Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-07 19:01:02+0700, Đoàn Trần Công Danh wrote:\n> On 2020-05-06 17:09:39+0200, Johannes Schindelin wrote:\n> > The idea is indeed very neat. I think we can do a bit better with resource\n> > usage by not even bothering to check this branch out. Something along\n> > those lines (sorry, I really would love to have the time to test this...):\n> \n> While this can avoid the cost of checking out a whole branch (which\n> can be mitigated by using an orphan branch with single file),\n> \n> This still spins up an VM, and actions/github-script run (I think)\n> nodejs, which is more resource intensive than git and sh script.\n> Above statement maybe wrong, I'm not interacting much with nodejs.\n\nI was wrong, actions/checkout is also using nodejs,\nSo, this actions/github-script actual reduces the total time for\nfetching the file ref-whitelist/ref-blacklist/allow-ref\n\n> > - id: check-ref\n> > name: check whether CI is enabled for ref\n> > uses: actions/github-script@0.9.0\n> > with:\n> > script: |\n> > const req = {\n> > owner: context.repo.owner,\n> > repo: context.repo.repo,\n> > ref: \"ci/config\"\n> > };\n> > \n> > try {\n> > req.tree_sha = (await github.git.getRef(req)).data.object.sha;\n> > (await github.git.getTree(req))\n> > .tree.filter(e => e.path == 'ref-whitelist').map(e => {\n> > req.file_sha = e.sha;\n> > });\n> > const list = Buffer.from((await github.git.getBlob(req)).data.content, 'base64').toString('UTF-8');\n> > core.setOutput('enabled', `\\n${list}`.indexOf(`\\n${{github.ref}}\\n`) < 0 ? 'no' : 'yes');\n> \n> And this `indexOf` will check if our ref (exact) matchs (full line)\n> with some white-list list, which is very limited.\n> So people couldn't match by some pattern (grep can work).\n> \n> I haven't tested, but we may use part of above script to read a single\n> file from a ref, and add another steps for \"grep\"/\"sh\"\n> I'm not sure if that script will cost more resources than git-checkout\n> or not. And is that solutions over-engineered?\n\nBut this point still hold, now, I think using part of above script to\nread the file, and allow more custom logic in a separated steps maybe\nbetter solutions.\n\n-- \nDanh\n"},{"id":"397307","messageId":"20200507140208.GA3060463@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200507121727.GA3057274@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-07T14:02:08Z","receivedAt":"2020-05-07T14:02:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 07, 2020 at 08:17:27AM -0400, Jeff King wrote:\n\n> > But doesn't this (i.e. uses: actions/github-script) still pay the\n> > cost of spinning up a VM? How expensive is it to check out a small\n> > tree with a single file, whether it is ref-whitelist or allow-ref?\n> \n> I suspect this script mechanism may be much cheaper. I don't know the\n> implementation details, but spinning up a nodejs container to run a\n> javascript snippet should be much cheaper than a full ubuntu VM running\n> \"git clone\" (the clone itself should be super cheap because it's a\n> shallow single-branch clone of a tree with one file in it, but getting\n> there is relatively heavy-weight).\n\nSorry, this is all complete nonsense. There is no magical nodejs\ncontainer in Actions. You still have to say \"runs-on: ubuntu-latest\". So\nit's still spinning up that VM and then running inside there.\n\nI just did a timing with three jobs:\n\n noop:\n runs-on: ubuntu-latest\n steps:\n - run: exit 0\n\n script:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/github-script@0.9.0\n with:\n script: |\n const req = {\n owner: context.repo.owner,\n repo: context.repo.repo,\n ref: \"refs/ci/config\"\n };\n\n try {\n req.tree_sha = (await github.git.getRef(req)).data.object.sha;\n (await github.git.getTree(req))\n .tree.filter(e => e.path == 'ref-whitelist').map(e => {\n req.file_sha = e.sha;\n });\n const list = Buffer.from((await github.git.getBlob(req)).data.content, 'base64').toString('UTF-8');\n core.setOutput('enabled', `\\n${list}`.indexOf(`\\n${{github.ref}}\\n`) < 0 ? 'no' : 'yes');\n } catch (e) {\n core.setOutput('enabled', 'yes');\n }\n\n checkout:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v2\n continue-on-error: true\n with:\n ref: refs/ci/config\n - run: ./allow-ref ${{ github.ref }}\n\nand they took 1, 2, and 3 seconds respectively. They spend 2s getting\nthe environment set up and the actions loaded. So the API one spent less\nthan 1s on the network, but the single-file checkout spent slightly\nmore. Given the timing variations I've seen, I wouldn't be surprised if\nit sometimes goes the other way. But even if those numbers are accurate,\nI don't think the cost difference is enough to force our hand either\nway.\n\n-Peff\n"},{"id":"397322","messageId":"20200507162011.GA3638906@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200505210451.GA645290@coredump.intra.peff.net","subject":"[PATCH v2] ci: allow per-branch config for GitHub Actions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-07T16:20:11Z","receivedAt":"2020-05-07T16:20:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2020 at 05:04:51PM -0400, Jeff King wrote:\n\n> Subject: [PATCH] ci: allow per-branch config for GitHub Actions\n\nHere's a \"v2\" of that patch based on the discussion.\n\nI think it smooths some of the rough edges of the orphan-branch\napproach, while still having a cost on par with other suggestions (or at\nleast ones that truly allow any config; we can check for \"for-ci/**\" or\nsomething very cheaply, but that implies hard-coding it for everybody).\nI think the cost here is acceptable, and it gives us room to add more\nfeatures in the future.\n\nIf Actions eventually adds per-repo variable storage that can be used in\n\"if:\" conditionals, then we could eventually switch to that. :)\n\nThe documentation here should be enough to let people work with it. But\nwe'd probably want to take Danh's patch to mention Actions in\nSubmittingPatches on top (and it possibly could be modified to point to\nthe ci/config directory).\n\n-- >8 --\nSubject: [PATCH] ci: allow per-branch config for GitHub Actions\n\nDepending on the workflows of individual developers, it can either be\nconvenient or annoying that our GitHub Actions CI jobs are run on every\nbranch. As an example of annoying: if you carry many half-finished\nwork-in-progress branches and rebase them frequently against master,\nyou'd get tons of failure reports that aren't interesting (not to\nmention the wasted CPU).\n\nThis commit adds a new job which checks a special branch within the\nrepository for CI config, and then runs a shell script it finds there to\ndecide whether to skip the rest of the tests. The default will continue\nto run tests for all refs if that branch or script is missing.\n\nThere have been a few alternatives discussed:\n\nOne option is to carry information in the commit itself about whether it\nshould be tested, either in the tree itself (changing the workflow YAML\nfile) or in the commit message (a \"[skip ci]\" flag or similar). But\nthese are frustrating and error-prone to use:\n\n - you have to manually apply them to each branch that you want to mark\n\n - it's easy for them to leak into other workflows, like emailing patches\n\nWe could likewise try to get some information from the branch name. But\nthat leads to debates about whether the default should be \"off\" or \"on\",\nand overriding still ends up somewhat awkward. If we default to \"on\",\nyou have to remember to name your branches appropriately to skip CI. And\nif \"off\", you end up having to contort your branch names or duplicate\nyour pushes with an extra refspec.\n\nBy comparison, this commit's solution lets you specify your config once\nand forget about it, and all of the data is off in its own ref, where it\ncan be changed by individual forks without touching the main tree.\n\nThere were a few design decisions that came out of on-list discussion.\nI'll summarize here:\n\n - we could use GitHub's API to retrieve the config ref, rather than a\n real checkout (and then just operate on it via some javascript). We\n still have to spin up a VM and contact GitHub over the network from\n it either way, so it ends up not being much faster. I opted to go\n with shell to keep things similar to our other tools (and really\n could implement allow-refs in any language you want). This also makes\n it easy to test your script locally, and to modify it within the\n context of a normal git.git tree.\n\n - we could keep the well-known refname out of refs/heads/ to avoid\n cluttering the branch namespace. But that makes it awkward to\n manipulate. By contrast, you can just \"git checkout ci-config\" to\n make changes.\n\n - we could assume the ci-config ref has nothing in it except config\n (i.e., a branch unrelated to the rest of git.git). But dealing with\n orphan branches is awkward. Instead, we'll do our best to efficiently\n check out only the ci/config directory using a shallow partial clone,\n which allows your ci-config branch to be just a normal branch, with\n your config changes on top.\n\n - we could provide a simpler interface, like a static list of ref\n patterns. But we can't get out of spinning up a whole VM anyway, so\n we might as well use that feature to make the config as flexible as\n possible. If we add more config, we should be able to reuse our\n partial-clone to set more outputs.\n\nSigned-off-by: Jeff King \n---\n .github/workflows/main.yml | 42 +++++++++++++++++++++++++++++++++++++\n ci/config/allow-refs.sample | 26 +++++++++++++++++++++++\n 2 files changed, 68 insertions(+)\n create mode 100755 ci/config/allow-refs.sample\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex fd4df939b5..802a4bf7cd 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -6,7 +6,39 @@ env:\n DEVELOPER: 1\n \n jobs:\n+ ci-config:\n+ runs-on: ubuntu-latest\n+ outputs:\n+ enabled: ${{ steps.check-ref.outputs.enabled }}\n+ steps:\n+ - name: try to clone ci-config branch\n+ continue-on-error: true\n+ run: |\n+ git -c protocol.version=2 clone \\\n+ --no-tags \\\n+ --single-branch \\\n+ -b ci-config \\\n+ --depth 1 \\\n+ --no-checkout \\\n+ --filter=blob:none \\\n+ https://github.com/${{ github.repository }} \\\n+ config-repo &&\n+ cd config-repo &&\n+ git checkout HEAD -- ci/config\n+ - id: check-ref\n+ name: check whether CI is enabled for ref\n+ run: |\n+ enabled=yes\n+ if test -x config-repo/ci/config/allow-ref &&\n+ ! config-repo/ci/config/allow-ref '${{ github.ref }}'\n+ then\n+ enabled=no\n+ fi\n+ echo \"::set-output name=enabled::$enabled\"\n+\n windows-build:\n+ needs: ci-config\n+ if: needs.ci-config.outputs.enabled == 'yes'\n runs-on: windows-latest\n steps:\n - uses: actions/checkout@v1\n@@ -70,6 +102,8 @@ jobs:\n name: failed-tests-windows\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n vs-build:\n+ needs: ci-config\n+ if: needs.ci-config.outputs.enabled == 'yes'\n env:\n MSYSTEM: MINGW64\n NO_PERL: 1\n@@ -154,6 +188,8 @@ jobs:\n ${{matrix.nr}} 10 t[0-9]*.sh)\n \"@\n regular:\n+ needs: ci-config\n+ if: needs.ci-config.outputs.enabled == 'yes'\n strategy:\n matrix:\n vector:\n@@ -189,6 +225,8 @@ jobs:\n name: failed-tests-${{matrix.vector.jobname}}\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n dockerized:\n+ needs: ci-config\n+ if: needs.ci-config.outputs.enabled == 'yes'\n strategy:\n matrix:\n vector:\n@@ -213,6 +251,8 @@ jobs:\n name: failed-tests-${{matrix.vector.jobname}}\n path: ${{env.FAILED_TEST_ARTIFACTS}}\n static-analysis:\n+ needs: ci-config\n+ if: needs.ci-config.outputs.enabled == 'yes'\n env:\n jobname: StaticAnalysis\n runs-on: ubuntu-latest\n@@ -221,6 +261,8 @@ jobs:\n - run: ci/install-dependencies.sh\n - run: ci/run-static-analysis.sh\n documentation:\n+ needs: ci-config\n+ if: needs.ci-config.outputs.enabled == 'yes'\n env:\n jobname: Documentation\n runs-on: ubuntu-latest\ndiff --git a/ci/config/allow-refs.sample b/ci/config/allow-refs.sample\nnew file mode 100755\nindex 0000000000..f157f1945a\n--- /dev/null\n+++ b/ci/config/allow-refs.sample\n@@ -0,0 +1,26 @@\n+#!/bin/sh\n+#\n+# Sample script for enabling/disabling GitHub Actions CI runs on\n+# particular refs. By default, CI is run for all branches pushed to\n+# GitHub. You can override this by dropping the \".sample\" from the script,\n+# editing it, committing, and pushing the result to the \"ci-config\" branch of\n+# your repository:\n+#\n+# git checkout -b ci-config\n+# cp allow-refs.sample allow-refs\n+# $EDITOR allow-refs\n+# git commit -am \"implement my ci preferences\"\n+# git push\n+#\n+# This script will then be run when any refs are pushed to that repository. It\n+# gets the fully qualified refname as the first argument, and should exit with\n+# success only for refs for which you want to run CI.\n+\n+case \"$1\" in\n+# allow one-off tests by pushing to \"for-ci\" or \"for-ci/mybranch\"\n+refs/heads/for-ci*) true ;;\n+# always build your integration branch\n+refs/heads/my-integration-branch) true ;;\n+# don't build any other branches or tags\n+*) false ;;\n+esac\n-- \n2.26.2.1005.ge383644752\n\n"},{"id":"397324","messageId":"20200507170042.GC26677@syl.local","threadId":"53374","inReplyTo":"20200507162011.GA3638906@coredump.intra.peff.net","subject":"Re: [PATCH v2] ci: allow per-branch config for GitHub Actions","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-05-07T17:00:42Z","receivedAt":"2020-05-07T17:00:47Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Hi Peff,\n\nOn Thu, May 07, 2020 at 12:20:11PM -0400, Jeff King wrote:\n> On Tue, May 05, 2020 at 05:04:51PM -0400, Jeff King wrote:\n>\n> > Subject: [PATCH] ci: allow per-branch config for GitHub Actions\n>\n> Here's a \"v2\" of that patch based on the discussion.\n\nI really like this direction. I think that it's a good mix of\nflexibility and convenience. I'm happy to push a one-time 'ci-config'\nbranch to 'ttaylorr/git' and forget about it.\n\n> I think it smooths some of the rough edges of the orphan-branch\n> approach, while still having a cost on par with other suggestions (or at\n> least ones that truly allow any config; we can check for \"for-ci/**\" or\n> something very cheaply, but that implies hard-coding it for everybody).\n> I think the cost here is acceptable, and it gives us room to add more\n> features in the future.\n>\n> If Actions eventually adds per-repo variable storage that can be used in\n> \"if:\" conditionals, then we could eventually switch to that. :)\n>\n> The documentation here should be enough to let people work with it. But\n> we'd probably want to take Danh's patch to mention Actions in\n> SubmittingPatches on top (and it possibly could be modified to point to\n> the ci/config directory).\n>\n> -- >8 --\n> Subject: [PATCH] ci: allow per-branch config for GitHub Actions\n>\n> Depending on the workflows of individual developers, it can either be\n> convenient or annoying that our GitHub Actions CI jobs are run on every\n> branch. As an example of annoying: if you carry many half-finished\n> work-in-progress branches and rebase them frequently against master,\n> you'd get tons of failure reports that aren't interesting (not to\n> mention the wasted CPU).\n>\n> This commit adds a new job which checks a special branch within the\n> repository for CI config, and then runs a shell script it finds there to\n> decide whether to skip the rest of the tests. The default will continue\n> to run tests for all refs if that branch or script is missing.\n>\n> There have been a few alternatives discussed:\n>\n> One option is to carry information in the commit itself about whether it\n> should be tested, either in the tree itself (changing the workflow YAML\n> file) or in the commit message (a \"[skip ci]\" flag or similar). But\n> these are frustrating and error-prone to use:\n>\n> - you have to manually apply them to each branch that you want to mark\n>\n> - it's easy for them to leak into other workflows, like emailing patches\n>\n> We could likewise try to get some information from the branch name. But\n> that leads to debates about whether the default should be \"off\" or \"on\",\n> and overriding still ends up somewhat awkward. If we default to \"on\",\n> you have to remember to name your branches appropriately to skip CI. And\n> if \"off\", you end up having to contort your branch names or duplicate\n> your pushes with an extra refspec.\n>\n> By comparison, this commit's solution lets you specify your config once\n> and forget about it, and all of the data is off in its own ref, where it\n> can be changed by individual forks without touching the main tree.\n>\n> There were a few design decisions that came out of on-list discussion.\n> I'll summarize here:\n>\n> - we could use GitHub's API to retrieve the config ref, rather than a\n> real checkout (and then just operate on it via some javascript). We\n> still have to spin up a VM and contact GitHub over the network from\n> it either way, so it ends up not being much faster. I opted to go\n> with shell to keep things similar to our other tools (and really\n> could implement allow-refs in any language you want). This also makes\n> it easy to test your script locally, and to modify it within the\n> context of a normal git.git tree.\n>\n> - we could keep the well-known refname out of refs/heads/ to avoid\n> cluttering the branch namespace. But that makes it awkward to\n> manipulate. By contrast, you can just \"git checkout ci-config\" to\n> make changes.\n>\n> - we could assume the ci-config ref has nothing in it except config\n> (i.e., a branch unrelated to the rest of git.git). But dealing with\n> orphan branches is awkward. Instead, we'll do our best to efficiently\n> check out only the ci/config directory using a shallow partial clone,\n> which allows your ci-config branch to be just a normal branch, with\n> your config changes on top.\n>\n> - we could provide a simpler interface, like a static list of ref\n> patterns. But we can't get out of spinning up a whole VM anyway, so\n> we might as well use that feature to make the config as flexible as\n> possible. If we add more config, we should be able to reuse our\n> partial-clone to set more outputs.\n>\n> Signed-off-by: Jeff King \n> ---\n> .github/workflows/main.yml | 42 +++++++++++++++++++++++++++++++++++++\n> ci/config/allow-refs.sample | 26 +++++++++++++++++++++++\n> 2 files changed, 68 insertions(+)\n> create mode 100755 ci/config/allow-refs.sample\n>\n> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> index fd4df939b5..802a4bf7cd 100644\n> --- a/.github/workflows/main.yml\n> +++ b/.github/workflows/main.yml\n> @@ -6,7 +6,39 @@ env:\n> DEVELOPER: 1\n>\n> jobs:\n> + ci-config:\n> + runs-on: ubuntu-latest\n> + outputs:\n> + enabled: ${{ steps.check-ref.outputs.enabled }}\n> + steps:\n> + - name: try to clone ci-config branch\n> + continue-on-error: true\n> + run: |\n> + git -c protocol.version=2 clone \\\n> + --no-tags \\\n> + --single-branch \\\n> + -b ci-config \\\n> + --depth 1 \\\n> + --no-checkout \\\n> + --filter=blob:none \\\n> + https://github.com/${{ github.repository }} \\\n> + config-repo &&\n> + cd config-repo &&\n> + git checkout HEAD -- ci/config\n> + - id: check-ref\n> + name: check whether CI is enabled for ref\n> + run: |\n> + enabled=yes\n> + if test -x config-repo/ci/config/allow-ref &&\n> + ! config-repo/ci/config/allow-ref '${{ github.ref }}'\n> + then\n> + enabled=no\n> + fi\n> + echo \"::set-output name=enabled::$enabled\"\n> +\n> windows-build:\n> + needs: ci-config\n> + if: needs.ci-config.outputs.enabled == 'yes'\n\nOne thing I wonder is whether the downstream 'windows-test' partitions.\nI think that it should be fine, since we won't run the dependent\n'windows-build', and then 'windows-test' won't have all of its\nprerequisites filled.\n\n> runs-on: windows-latest\n> steps:\n> - uses: actions/checkout@v1\n> @@ -70,6 +102,8 @@ jobs:\n> name: failed-tests-windows\n> path: ${{env.FAILED_TEST_ARTIFACTS}}\n> vs-build:\n> + needs: ci-config\n> + if: needs.ci-config.outputs.enabled == 'yes'\n> env:\n> MSYSTEM: MINGW64\n> NO_PERL: 1\n> @@ -154,6 +188,8 @@ jobs:\n> ${{matrix.nr}} 10 t[0-9]*.sh)\n> \"@\n> regular:\n> + needs: ci-config\n> + if: needs.ci-config.outputs.enabled == 'yes'\n> strategy:\n> matrix:\n> vector:\n> @@ -189,6 +225,8 @@ jobs:\n> name: failed-tests-${{matrix.vector.jobname}}\n> path: ${{env.FAILED_TEST_ARTIFACTS}}\n> dockerized:\n> + needs: ci-config\n> + if: needs.ci-config.outputs.enabled == 'yes'\n> strategy:\n> matrix:\n> vector:\n> @@ -213,6 +251,8 @@ jobs:\n> name: failed-tests-${{matrix.vector.jobname}}\n> path: ${{env.FAILED_TEST_ARTIFACTS}}\n> static-analysis:\n> + needs: ci-config\n> + if: needs.ci-config.outputs.enabled == 'yes'\n> env:\n> jobname: StaticAnalysis\n> runs-on: ubuntu-latest\n> @@ -221,6 +261,8 @@ jobs:\n> - run: ci/install-dependencies.sh\n> - run: ci/run-static-analysis.sh\n> documentation:\n> + needs: ci-config\n> + if: needs.ci-config.outputs.enabled == 'yes'\n> env:\n> jobname: Documentation\n> runs-on: ubuntu-latest\n> diff --git a/ci/config/allow-refs.sample b/ci/config/allow-refs.sample\n> new file mode 100755\n> index 0000000000..f157f1945a\n> --- /dev/null\n> +++ b/ci/config/allow-refs.sample\n> @@ -0,0 +1,26 @@\n> +#!/bin/sh\n> +#\n> +# Sample script for enabling/disabling GitHub Actions CI runs on\n> +# particular refs. By default, CI is run for all branches pushed to\n> +# GitHub. You can override this by dropping the \".sample\" from the script,\n> +# editing it, committing, and pushing the result to the \"ci-config\" branch of\n> +# your repository:\n> +#\n> +# git checkout -b ci-config\n\nShould we be recommending '--orphan' instead of '-b' here? It looks\nlike when you clone this branch down that you try to get as few bytes as\npossible, so I figure it may be easier to have this be a orphaned\nbranch.\n\n> +# cp allow-refs.sample allow-refs\n> +# $EDITOR allow-refs\n> +# git commit -am \"implement my ci preferences\"\n> +# git push\n> +#\n> +# This script will then be run when any refs are pushed to that repository. It\n> +# gets the fully qualified refname as the first argument, and should exit with\n> +# success only for refs for which you want to run CI.\n> +\n> +case \"$1\" in\n> +# allow one-off tests by pushing to \"for-ci\" or \"for-ci/mybranch\"\n> +refs/heads/for-ci*) true ;;\n> +# always build your integration branch\n> +refs/heads/my-integration-branch) true ;;\n> +# don't build any other branches or tags\n> +*) false ;;\n> +esac\n> --\n> 2.26.2.1005.ge383644752\n>\n\nThanks,\nTaylor\n"},{"id":"397325","messageId":"20200507171840.GA3645692@coredump.intra.peff.net","threadId":"53374","inReplyTo":"20200507170042.GC26677@syl.local","subject":"Re: [PATCH v2] ci: allow per-branch config for GitHub Actions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-07T17:18:40Z","receivedAt":"2020-05-07T17:18:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 07, 2020 at 11:00:42AM -0600, Taylor Blau wrote:\n\n> > windows-build:\n> > + needs: ci-config\n> > + if: needs.ci-config.outputs.enabled == 'yes'\n> \n> One thing I wonder is whether the downstream 'windows-test' partitions.\n> I think that it should be fine, since we won't run the dependent\n> 'windows-build', and then 'windows-test' won't have all of its\n> prerequisites filled.\n\nYes, I intentionally left them out for that reason. It seemed simpler to\njust let the skip percolate down the dependency tree.\n\n> > +# Sample script for enabling/disabling GitHub Actions CI runs on\n> > +# particular refs. By default, CI is run for all branches pushed to\n> > +# GitHub. You can override this by dropping the \".sample\" from the script,\n> > +# editing it, committing, and pushing the result to the \"ci-config\" branch of\n> > +# your repository:\n> > +#\n> > +# git checkout -b ci-config\n> \n> Should we be recommending '--orphan' instead of '-b' here? It looks\n> like when you clone this branch down that you try to get as few bytes as\n> possible, so I figure it may be easier to have this be a orphaned\n> branch.\n\nNo, the whole point of doing the partial clone (rather than using\nactions/checkout, which doesn't support that) was so people didn't have\nto deal with the orphan-branch thing.\n\n-Peff\n"},{"id":"397330","messageId":"xmqqimh74njl.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200507140208.GA3060463@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-07T18:17:50Z","receivedAt":"2020-05-07T18:17:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, May 07, 2020 at 08:17:27AM -0400, Jeff King wrote:\n>\n>> > But doesn't this (i.e. uses: actions/github-script) still pay the\n>> > cost of spinning up a VM? How expensive is it to check out a small\n>> > tree with a single file, whether it is ref-whitelist or allow-ref?\n>> \n>> I suspect this script mechanism may be much cheaper. I don't know the\n>> implementation details, but spinning up a nodejs container to run a\n>> javascript snippet should be much cheaper than a full ubuntu VM running\n>> \"git clone\" (the clone itself should be super cheap because it's a\n>> shallow single-branch clone of a tree with one file in it, but getting\n>> there is relatively heavy-weight).\n>\n> Sorry, this is all complete nonsense. There is no magical nodejs\n> container in Actions. You still have to say \"runs-on: ubuntu-latest\". So\n> it's still spinning up that VM and then running inside there.\n\nAh, I did see \"runs-on: ubuntu-latest\" in the tutorial for the node\nthing, and was very much dissapointed, before I sent that \"don't you\nstill spin up a VM anyway?\" response. Glad to know that I wasn't\ntotally misreading the documentation, and unhappy that there wasn't\na magic bullet after all X-<.\n\n> and they took 1, 2, and 3 seconds respectively. They spend 2s getting\n> the environment set up and the actions loaded. So the API one spent less\n> than 1s on the network, but the single-file checkout spent slightly\n> more. Given the timing variations I've seen, I wouldn't be surprised if\n> it sometimes goes the other way. But even if those numbers are accurate,\n> I don't think the cost difference is enough to force our hand either\n> way.\n\nYup, the above tempts me to say \"because we are spinning a VM\nanyway, why not just run an end-user supplied script and let it\ndecide?\" would be the best approach.\n\nUnless somebody finds a magic bullet, that is, but unfortunately the\nnodejs one does not seem to be one.\n\nThanks.\n\n"},{"id":"397331","messageId":"xmqqeerv4n0q.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200507122549.GB3057274@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-07T18:29:09Z","receivedAt":"2020-05-07T18:29:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yeah, I agree that all of the mechanisms for dealing with the unrelated\n> history are somewhat awkward. Another issue is that you can't just:\n>\n> git clone --single-branch -b refs/ci/config my-config\n>\n> to work on it, because \"-b\" wants only heads or tags (we could address\n> that by putting it in refs/heads/ci-config or similar).\n\nI somehow don't think that it is such a huge issue, because I expect\nanybody who has legitimate interest in refs/ci/config to have a full\nclone of git.git anyway. So it is more like defining another\nremote.origin.fetch like this:\n\n\t [remote \"origin\"]\n\t \turl = https://git.kernel.org/pub/scm/git/git.git/\n\t \tfetch = +refs/heads/*:refs/remotes/origin/*\n\t+\tfetch = +refs/ci/config:refs/remotes/origin/ci-config\n\n [remote \"publish\"]\n\t\turl = https://github.com/user/git/\n\n\nand then do something like:\n \n\t$ git worktree add -b ci-config ../git-ci-config origin/ci-config\n\t$ cd ../git-ci-config\n\t... hack hack hack ...\n\t$ git push publish ci-config:refs/ci/config\n\n> If we do go the javascript route, perhaps it would make sense for\n> refs/ci/config to be a single blob containing a snippet of javascript\n> with several functions. And then we could just eval() that and call the\n> appropriate functions (if defined).\n\nYup.\n\n> Then a sample can live in the main repo with something like:\n>\n> # This file contains functions which will be run by the GitHub\n> # Actions CI script.\n> #\n> # You may customize it for your own fork by modifying it on any branch\n> # you like, and installing with:\n> #\n> # git push $(git rev-parse HEAD:ci/config):refs/ci/config\n> #\n> # [allow_ref() sample definition and documentation....]\n>\n> That sidesteps most of those issues.\n\nPerhaps.\n"},{"id":"397333","messageId":"20200507185405.GA23736@coredump.intra.peff.net","threadId":"53374","inReplyTo":"xmqqeerv4n0q.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-07T18:54:05Z","receivedAt":"2020-05-07T18:54:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 07, 2020 at 11:29:09AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Yeah, I agree that all of the mechanisms for dealing with the unrelated\n> > history are somewhat awkward. Another issue is that you can't just:\n> >\n> > git clone --single-branch -b refs/ci/config my-config\n> >\n> > to work on it, because \"-b\" wants only heads or tags (we could address\n> > that by putting it in refs/heads/ci-config or similar).\n> \n> I somehow don't think that it is such a huge issue, because I expect\n> anybody who has legitimate interest in refs/ci/config to have a full\n> clone of git.git anyway. So it is more like defining another\n> remote.origin.fetch like this:\n> \n> \t [remote \"origin\"]\n> \t \turl = https://git.kernel.org/pub/scm/git/git.git/\n> \t \tfetch = +refs/heads/*:refs/remotes/origin/*\n> \t+\tfetch = +refs/ci/config:refs/remotes/origin/ci-config\n> \n> [remote \"publish\"]\n> \t\turl = https://github.com/user/git/\n> \n> \n> and then do something like:\n> \n> \t$ git worktree add -b ci-config ../git-ci-config origin/ci-config\n> \t$ cd ../git-ci-config\n> \t... hack hack hack ...\n> \t$ git push publish ci-config:refs/ci/config\n\nI dunno. The duality of refs/ci/config and refs/heads/ci-config is\nweird. Your two refspecs overlap on their RHS, and once you push up the\nrefs/heads/ci-config you created with \"git worktree add\", they'll start\nto conflict (which maybe is OK as long as they're the same).\n\nIn the patch I sent out a few hours ago I just caved and made\nrefs/heads/ci-config the magic ref, in order to avoid complexity.\n\nBut it also wouldn't be too bad to say \"look, you can store this however\nyou like in refs/heads/ or not at all, but install it into place with\ngit push HEAD:refs/ci/config\". The audience is git.git\ndevelopers (and even advanced ones whose workflows involve tweaking\ntheir CI config), so I'd like to think they could figure it out.\n\nI have a feeling that fewer than 5 people in the world will end up using\nthis feature either way. ;)\n\n-Peff\n"},{"id":"397338","messageId":"xmqq1rnv4k1n.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200507185405.GA23736@coredump.intra.peff.net","subject":"Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-07T19:33:24Z","receivedAt":"2020-05-07T19:33:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> In the patch I sent out a few hours ago I just caved and made\n> refs/heads/ci-config the magic ref, in order to avoid complexity.\n>\n> But it also wouldn't be too bad to say \"look, you can store this however\n> you like in refs/heads/ or not at all, but install it into place with\n> git push HEAD:refs/ci/config\". The audience is git.git\n> developers (and even advanced ones whose workflows involve tweaking\n> their CI config), so I'd like to think they could figure it out.\n>\n> I have a feeling that fewer than 5 people in the world will end up using\n> this feature either way. ;)\n\nYeah, let's not spend too much time and too many cycles to\noverengineer it.\n\nThanks.\n"},{"id":"397344","messageId":"xmqqwo5n34ka.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200507162011.GA3638906@coredump.intra.peff.net","subject":"Re: [PATCH v2] ci: allow per-branch config for GitHub Actions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-07T19:53:09Z","receivedAt":"2020-05-07T19:53:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> + - id: check-ref\n> + name: check whether CI is enabled for ref\n> + run: |\n> + enabled=yes\n> + if test -x config-repo/ci/config/allow-ref &&\n> + ! config-repo/ci/config/allow-ref '${{ github.ref }}'\n\nIs it deliberate that the output from the script is not redirected\nto >/dev/null, which would mean they are allowed to do something\nthat looks like:\n\n\t\techo \"::set-output name=enabled::frotz\"\n\nor emit other random ::string-that-affects-github-actions to its\nstandard output stream?\n\n> + then\n> + enabled=no\n> + fi\n> + echo \"::set-output name=enabled::$enabled\"\n"},{"id":"397351","messageId":"20200507204626.GG29683@coredump.intra.peff.net","threadId":"53374","inReplyTo":"xmqqwo5n34ka.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2] ci: allow per-branch config for GitHub Actions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-07T20:46:26Z","receivedAt":"2020-05-07T20:46:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 07, 2020 at 12:53:09PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > + - id: check-ref\n> > + name: check whether CI is enabled for ref\n> > + run: |\n> > + enabled=yes\n> > + if test -x config-repo/ci/config/allow-ref &&\n> > + ! config-repo/ci/config/allow-ref '${{ github.ref }}'\n> \n> Is it deliberate that the output from the script is not redirected\n> to >/dev/null, which would mean they are allowed to do something\n> that looks like:\n> \n> \t\techo \"::set-output name=enabled::frotz\"\n> \n> or emit other random ::string-that-affects-github-actions to its\n> standard output stream?\n\nIt was deliberate in the sense that I would allow them to write useful\nmessages to the Actions log. If they want to do nonsense like\n\"::set-output\", then it's their foot and their gun.\n\nI don't know if Actions distinguishes between stdout and stderr here\n(i.e., if we redirected the script's stdout to stderr, would that\nprevent this case or not?).\n\n-Peff\n"},{"id":"397361","messageId":"xmqqo8qz2yrr.fsf@gitster.c.googlers.com","threadId":"53374","inReplyTo":"20200507204626.GG29683@coredump.intra.peff.net","subject":"Re: [PATCH v2] ci: allow per-branch config for GitHub Actions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-07T21:58:16Z","receivedAt":"2020-05-07T21:58:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> It was deliberate in the sense that I would allow them to write useful\n> messages to the Actions log. If they want to do nonsense like\n> \"::set-output\", then it's their foot and their gun.\n\nIt's not like fooling the framework you laid out here is a\npotentially useful attack vector. We can assume that it is unlikely\nfor the custom allow-ref to be writing a string that happens to\nbegin with double-colon by mistake and making it harder to debug.\n\n> I don't know if Actions distinguishes between stdout and stderr here\n> (i.e., if we redirected the script's stdout to stderr, would that\n> prevent this case or not?).\n\nPerhaps we can experiment with \"echo >&2 we are getting called\" in\nthe allow-ref script itself ;-).\n\nIn any case, I'll queue it on 'pu'. Thanks.\n\n"},{"id":"397432","messageId":"20200508180047.GD637136@coredump.intra.peff.net","threadId":"53374","inReplyTo":"xmqqo8qz2yrr.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v2] ci: allow per-branch config for GitHub Actions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-05-08T18:00:47Z","receivedAt":"2020-05-08T18:00:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 07, 2020 at 02:58:16PM -0700, Junio C Hamano wrote:\n\n> In any case, I'll queue it on 'pu'. Thanks.\n\nI just noticed this needs a small fix to the sample script, which I gave\nthe wrong name:\n\ndiff --git a/ci/config/allow-refs.sample b/ci/config/allow-ref.sample\nsimilarity index 93%\nrename from ci/config/allow-refs.sample\nrename to ci/config/allow-ref.sample\nindex f157f1945a..c9c9aea9ff 100755\n--- a/ci/config/allow-refs.sample\n+++ b/ci/config/allow-ref.sample\n@@ -7,8 +7,8 @@\n # your repository:\n #\n # git checkout -b ci-config\n-# cp allow-refs.sample allow-refs\n-# $EDITOR allow-refs\n+# cp allow-refs.sample allow-ref\n+# $EDITOR allow-ref\n # git commit -am \"implement my ci preferences\"\n # git push\n #\n\n> Perhaps we can experiment with \"echo >&2 we are getting called\" in\n> the allow-ref script itself ;-).\n\nThat definitely ends up in the log. But doing:\n\n echo \"::error file=foo.sh,line=1,col=2::this is the stdout msg\"\n echo >&2 \"::error file=foo.sh,line=1,col=2::this is the stderr msg\"\n\nshows both versions formatted in red, which implies to me that stdout\nand stderr are treated the same.\n\n-Peff\n"},{"id":"397445","messageId":"20200509012304.GB2111@danh.dev","threadId":"53374","inReplyTo":"20200508180047.GD637136@coredump.intra.peff.net","subject":"Re: [PATCH v2] ci: allow per-branch config for GitHub Actions","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2020-05-09T01:23:04Z","receivedAt":"2020-05-09T01:23:13Z","isPatch":true,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2020-05-08 14:00:47-0400, Jeff King wrote:\n> I just noticed this needs a small fix to the sample script, which I gave\n> the wrong name:\n> \n> diff --git a/ci/config/allow-refs.sample b/ci/config/allow-ref.sample\n> similarity index 93%\n> rename from ci/config/allow-refs.sample\n> rename to ci/config/allow-ref.sample\n> index f157f1945a..c9c9aea9ff 100755\n> --- a/ci/config/allow-refs.sample\n> +++ b/ci/config/allow-ref.sample\n> @@ -7,8 +7,8 @@\n> # your repository:\n> #\n> # git checkout -b ci-config\n> -# cp allow-refs.sample allow-refs\n> -# $EDITOR allow-refs\n> +# cp allow-refs.sample allow-ref\n\nHi Peff,\n\nThe source needs to be changed, too:\n---------------8<-------------\ndiff --git a/ci/config/allow-ref.sample b/ci/config/allow-ref.sample\nindex c9c9aea9ff..249872425f 100755\n--- a/ci/config/allow-ref.sample\n+++ b/ci/config/allow-ref.sample\n@@ -7,7 +7,7 @@\n # your repository:\n #\n # git checkout -b ci-config\n-# cp allow-refs.sample allow-ref\n+# cp allow-ref.sample allow-ref\n # $EDITOR allow-ref\n # git commit -am \"implement my ci preferences\"\n # git push\n--------------------8<------------------\n\n-- \nDanh\n"}]}