cuelang.org: CI workflow sometimes fails while handling tip

[jpluscplusm]

What page were you looking at?

https://cuelang.org/

What version of the site were you looking at?

https://github.com/cue-lang/cuelang.org/commit/f414e389cb4880b575e1c7754a32166017fe3ce2

Problem

The tip.cuelang.org: Deploy the site step failed recently, after two cue-lang/cue CLs were submitted in rapid succession. The failing step's output is as follows, emitted by the _scripts/tipDeploy.bash script:

add 'content/docs/concept/how-cue-works-with-json/en.md'
[ ... 221 lines elided ... ]
add 'content/examples/cue/preprocessor/gen_cache.cue'
[master c97d0927] tip.cuelang.org: cache files for 3a55072f
 223 files changed, 663 insertions(+), 696 deletions(-)
Pushing to https://github.com/cue-lang/cuelang.org
POST git-receive-pack (167938 bytes)
To https://github.com/cue-lang/cuelang.org
 ! [remote rejected]   HEAD -> tip (cannot lock ref 'refs/heads/tip': is at 650e09d1866c95b4cab162c7fc939906ab09918f but expected f9e86c07e3c7343ad467a8a067d6743ad0ff0ed8)
error: failed to push some refs to 'https://github.com/cue-lang/cuelang.org'

It's believed that both cue-lang/cue CLs being submitted triggered the cue-lang/cuelang.org trybot on master twice, and by the time one of them reached the git-push-to-tip stage, the other had already pushed to tip- causing some kind of remote GitHub failure.

It's not clear why this caused a problem, given that the script uses git push --force. It's not even certain that this was the proximate cause of the failure, or that the failing workflow was the second one to reach that point in the trybot workflow.

[jpluscplusm]

One possible fix we've discussed would also solve the lack of sequencing inherent in our current tip handling:

• move the tip-related steps into a separate workflow
• trigger that workflow on pushes to the master branch of cue-lang/cue and cue-lang/cuelang.org
• configure that workflow to have a concurrency of 1 to (attempt to) enforce sequencing.

We could also set cancel-in-progress: true on the workflow to not waste processing effort, as the only state that's important is the pass/fail status of the current tip of master of both repos combined.