Bad concurrency for prod deploys about docs HOT 5 OPEN

Interesting issue! Despite being less ideal, in this case I think we could fix it by having newest commits cancelling previous ongoing builds 👀 that'd effectively solve the problem and I don't see significant drawbacks.

Not sure how to achieve this with CircleCI though, and I won't have time to investigate this any time soon 😥 happy to review PRs or other changes in the meantime though!

from docs.

I'm used to the behaviour needed in GHA but it seems it's not exactly that straightforward in CircleCI:

• https://discuss.circleci.com/t/limiting-concurrent-workflows-and-jobs/44699
• https://discuss.circleci.com/t/avoid-concurrent-workflows-on-main-branch/46148/2
• https://discuss.circleci.com/t/workaround-auto-cancel-redundant-builds-on-the-default-branch/39468/19 🤦‍♂️

So my take would simply be:

but only in master context / publish CI, not when run otherwise, manually/localy etc. as there might be more users of the script — so I'm not confident to just propose -f there and call it a day. Leaving that to others to come up with something maybe more sophisticated;]

(This would be still far from perfect, as that doesn't prefer the build that starts last, but one that finishes last, and that's a huge difference;)… throw in some timeout, connection/performance or cache woes like lately, and you can have an older commit overwriting the output of a newer one just by getting stuck for a bit longer in there…) 🤷‍♂️

from docs.

Thanks for digging that info for CircleCI. It seems like they don't offer "auto cancel builds" which's kinda underwhelming 🤕 I wouldn't expect that.

Some alternative solutions:

• Do the deploy in a different CI (probably possible in their free tier, given that we barely deploy), even e.g. GHA.
• Use -f but then also have a cron job that re-deploys once a day just in case 🤷
• Restart the deployment in case it fails during that step? Basically catch the error, and treat it by retrying. Retry a given amount of times, e.g. 3, 5…
• Only deploy when creating tags (I dislike this option as it actually decreases the deployment frequency and adds an extra step for us maintainers to deploy changes 🙈 )

Thoughts?

from docs.

Yea we've had race conditions e.g. where a workflow would need a docker built from the same sha that might not have already been published to the registry, so the cron fallback for failed pipelines sounds uncomfortably familiar;]

The build is simple enough to be pushed straight to a deployment environment via GHA, getting rid of the gh-pages branch and its underlying git tree completely, and I'd welcome that — but I don't think you can depend GHA running only if previous checks i.e. CircleCI build&test pass. The containerised fastlanetools/ci test image is just docker anyways so that shouldn't be too prohibitive to move that also to GHA, keeping the whole CI just here… but it would mean disjoining pipelines from fastlane/fastlane which is kinda 💩…

from docs.

But the problem is pretty trivial in this case. The bundler woes slowed down the CI and it took ~10mins and more from initial checkout to the actual switch & commit step, so before resorting to bigger changes or force pushing I'd just try #1250 adding an extra fetch — to check out fresh gh-pages tip instead of the head that's been lying around for minutes already… (at the same time the current bundler version resolves take only seconds, so that should help avoiding conflicts too…)

from docs.