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: >> >>> On 11/7/22 2:53 PM, Taylor Blau wrote: > >>>> I wonder how we should treat Ævar's concerns in this thread. I suspect >>>> that the vast majority of workflows wouldn't be affected, but I don't >>>> want to completely break Ævar's workflow, either ;-). >>>> >>>> Some kind of configuration mechanism like I proposed might be nice. >>>> Thoughts? >>> >>> Taking a look at that sub-thread, I have two thoughts: >>> >>> 1. I don't think supporting a "multiple pushes of WIP work" >>> scenario is a good use of "free" resources. If you want to >>> test multiple versions of something, then use multiple >>> branches (and I think Johannes's patch allows concurrent >>> builds for distinct branch names). >> >> The setting Taylor proposed in >> https://lore.kernel.org/git/Y2R3vJf1A2KOZwA7@nand.local/ is off by >> default, i.e. it would behave the same way as what Johannes is >> proposing, just give you (well, me) an opt-out from the default, without >> patching main.yml on every branch. >> >> So it seems like a win-win, why force others to change their workflow? >> Sure, I could push multiple branches, but you could also manually cancel >> your outstanding jobs before re-pushing... >> >> I agree that cancelling the outstanding job is a better default, and if >> we had to pick one or the other I'd say "sure", but if we can have >> both... > >>> 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 don't think you can be wrong about #1, "others should change their >> workflow to fit a new worldview" is more of a value-judgment :) > > True, but I think that the workflow you are trying to keep valid > is also indistinguishable to the typical flow of force-pushing > during incremental rewrites, so preserving your workflow will > continue to add costs to that behavior. I don't think it will, per the above. I mean, pedantically yes: But the cost of that "test -x and variable setting" is so trivial that it's not worth worrying about. > My value judgement is that experts can adapt their workflows as > situations change for the better of the group. Sure, I agree with that in zero-sum scenarios, or where it's a hassle to provide two things, and we need to pick one etc. I just don't see that being the case here. > If the cost of doing the config option version is minimal over > the global concurrency issue, then I say we should go that route. > I just expect it to take up more resources than the strategy > proposed in the initial patch. Based on what? That you read it as us cloning the ci-config repo just for this new proposed config, and missed that we're doing it already, or ...? > 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.
