On 11/7/2022 5:56 PM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Nov 07 2022, Derrick Stolee wrote: > >> On 11/7/22 4:03 PM, Ævar Arnfjörð Bjarmason wrote: >>> >>> On Mon, Nov 07 2022, Derrick Stolee wrote: >>>> Either of these points may have an incorrect assumption, so >>>> I'm prepared to be wrong. >>> >>> I *think* you're wrong about #2, but I'm not sure either. >> >> At the very least, the configurable option requires fetching the >> repo and checking out at least one file. I don't know how much it >> actually saves one way or another. > > It's already fetching the ci-config repo, so we're talking about the > marginal cost of running the bit of shellscript to check if > config-repo/ci/config/skip-concurrent is executable, and if not keeping > the default config. >> I wonder how we could determine this. Should we run a few CI >> jobs with some force-pushes in either approach (config turned >> off) so we know that cost? > > The incremental cost of that "test -x", or...? I'm not sure what you > mean here. The difference is that setting the concurrency globally allows Actions to decide the concurrency from the workflow file alone, before any jobs are run. This is done without a clone. The method introduced in e76eec35540 (ci: allow per-branch config for GitHub Actions, 2020-05-07) requires running the ci-config job at minimum to set the concurrency value, which involves doing a (very small, shallow) clone of the ci-config branch to determine if that file exists. Since this is the first job to run in the workflow, the global concurrency will only reduces the amount of compute consumed when pushes happen close together, but that is included for "oops I forgot to --amend" and other common cases. At the very least, the difference between the two mechanisms is greater than a 'test -x'. Thanks, -Stolee
