# Description of Changes
`Internal Tests` invoke another workflow. If the calling workflow is
cancelled, now we also cancel the invoked workflow.
# API and ABI breaking changes
None.
# Expected complexity level and risk
2
# Testing
- [x] Push multiple commits to this PR, see that the invoked job is
cancelled
- [x] Manually cancel the `Internal Tests` job, see that the invoked job
is cancelled
---------
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Switch the `Internal Tests` job to re-use the existing CI workflow
instead of a separate one.
# API and ABI breaking changes
None. CI only.
# Expected complexity level and risk
1
# Testing
- [x] Internal Tests passes on this PR
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
I allowed chatgpt to mislead me about how to do these format strings.
Apparently this is the wrong syntax. I've now verified the correct
syntax:
https://docs.github.com/en/actions/reference/workflows-and-actions/expressions#format
# API and ABI breaking changes
CI only.
# Expected complexity level and risk
1
# Testing
I honestly don't know how to check what concurrency group something is
running in..
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
For some reason, the Internal Tests have trouble fetching the commit
sha, especially when the job is re-run. This PR switches it to using ref
names rather than commit sha, because the ref names are much more
durable than GitHub's ephemeral commits that it generates during
workflows.
# API and ABI breaking changes
None. CI only.
# Expected complexity level and risk
1
# Testing
- [x] CI still passes
- [x] Ref still gets checked out successfully on re-run.
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
The merge queue was (partly) getting borked because we were putting all
non-PR CI events into the same concurrency group, which meant they all
non-PR CI jobs would run sequentially instead of running in parallel.
This sometimes caused _painfully_ long delays in the merge queue.
This was due to my misunderstanding in
https://github.com/clockworklabs/SpacetimeDB/pull/3501#discussion_r2466570395,
where I didn't realize that `cancel-in-progress: false` would cause
everything to queue up.
Now, for non-PR events, we append the commit SHA to the concurrency
group. For merge queue events, this should be the SHA of the ephemeral
merge commit that GH creates, so it will never conflict. For push events
or manual workflow dispatch events, the SHA should be a sane way to
recognize/cancel redundant events.
# API and ABI breaking changes
None. CI-only change.
# Expected complexity level and risk
1
# Testing
- [x] PR CI passes on this PR
- [x] PR CI is still canceled on this PR if a new commit is pushed
Unfortunately it's hard to test the behavior for non-PR events without
merging and seeing if it works.
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
These tests fail on external PRs, but not for any real reasons - just
because GH secrets are missing. "Skipped" is more informative than
"failed".
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
None, but I just copied the logic from the unity testsuite.
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Add `cancel-in-progress` to our GitHub workflows.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] Pushing new commits to this PR causes cancels of previous CI runs
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Zeke Foppa