search

tetsuharuohzeki / fastly-compute-template

Starter example repository customized heavily including an integration test infrastructure for Fastly Compute
https://docs.fastly.com/products/compute
MIT License
0 stars 0 forks source link

Improve job throughput of CI workflow for trunk #30

Open tetsuharuohzeki opened 2 years ago

tetsuharuohzeki commented 2 years ago

see https://github.com/tetsuharuohzeki/fastly-compute-at-edge-template/pull/28#issuecomment-1164923712

tetsuharuohzeki commented 2 years ago

By the experiment in https://github.com/tetsuharuohzeki/fastly-compute-at-edge-template/pull/29, I seem our hypothesis is true.

However, we need configure the concurrency group to use that optimization because it use github.ref.
https://github.com/tetsuharuohzeki/fastly-compute-at-edge-template/blob/72c7584d22d224cab55778d36dd2c545daa6e923/.github/workflows/ci.yaml#L9

Our current design caps the workflow concurrency at the top level workflow. So the concurrency group will not conflict. However, if we remove the top level concurrency group, then the child level concurrency group will be used.

tetsuharuohzeki commented 2 years ago

Our current design caps the workflow concurrency at the top level workflow. So the concurrency group will not conflict. However, if we remove the top level concurrency group, then the child level concurrency group will be used.

I experiment this design at #31 but it cannot resolve this perf issue.

By this design, deploy job is queued after all dependencies are completed. This mean that the lock by the concurrency group by delopy job is registered on that all dependencies are completed.

So if predecessor delays to complete their dependencies, successor will begin to run delopy job ahead of the predecessor. This cannot achieve our intention.