search

buildkite / feedback

Got feedback? Please let us know!
https://buildkite.com
25 stars 24 forks source link

Parallel steps with parallelism=1 should not show as parallel #493

Closed joscha closed 5 years ago

joscha commented 5 years ago

We auto-generate our buildkite pipelines dynamically and some steps have parallelism: 1 where the number is determined automatically.

Since https://buildkite.com/changelog/42-parallel-jobs-now-show-as-a-single-group these show like:

web__build_editor__36004

It would be great if parallelism: 1 would just show like any other non-parallel step.

ticky commented 5 years ago

Hah! Good catch 😅

joscha commented 5 years ago

Not a biggie but related: web__build_editor__36107

(the overview step seems to acquire the number of the first run for %n)

ticky commented 5 years ago

Yep, that’s what we’re expecting for now. We’re figuring people are more likely to drop the number now that the parallel step numbers are first-class citizens!

petemounce commented 5 years ago

This works great for the UI - I think, though, that the github status check API is based on the first completed shard, rather than waiting for all the parallel jobs to complete? When I tried this, clicked a detail link from GitHub, I arrived at the 1/10 shard. When I checked on a rebuild and hit the in-progress details link for the step I'd just parallelised, I got the 5/10 one.

This totally scientific approach makes me suspect the status check name is the same for every shard, meaning that the check goes green on the first pass, not the last pass.

I think this means a PR with parallelised steps can be merged before all the shards complete - in fact, I suppose it might flap the mergability if some pass and some fail.

I would want the github status check name to remain the same, since otherwise my branch protection needs to be parallelism aware, and it strikes me that's something likely to be dynamic according to the degree of parallelism we choose - and CI and github would then need to be in sync, which I'd want to avoid.

keithpitt commented 5 years ago

I think, though, that the github status check API is based on the first completed shard, rather than waiting for all the parallel jobs to complete?

@petemounce you're spot on, and we consider this a design flaw / bug with our implementation. We'll get it fixed! Currently the implementation is pretty racey depending on which one finishes. We should be treating them as a single entity when it comes to commit statuses.