# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
The objective here is to get rid of the arm runner that we have deployed
which is very much underutilized and sometimes during the release is the
bottleneck because it can only run a small amount of jobs at any given
time. Instead, we will cross compile to ARM on our existing x86 github
runner fleet.
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
None - CI only change.
# Expected complexity level and risk
1 - CI only change
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
https://github.com/clockworklabs/SpacetimeDB/actions/runs/26833018052
# Description of Changes
Use an AWS bucket for client binaries instead of DigitalOcean.
Note that this will effectively hamstring the DigitalOcean mirror for
any old clients (i.e. ones before this change is released). But it's
only a mirror, and they can "fix" it by upgrading to a version with this
change.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] Manually ran the package job on this PR and confirmed that some of
the resulting URLs are indeed downloadable from the AWS urls
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Add EV code signing for Windows CLI binaries using DigiCert KeyLocker.
The workflow now signs `spacetimedb-update.exe`, `spacetimedb-cli.exe`,
and `spacetimedb-standalone.exe` on tag pushes using `smctl sign` with a
cloud HSM-backed certificate.
These changes reflect the updated DigiCert guidance for code signing
through GitHub found here:
https://github.com/marketplace/actions/digicert-binary-signing
# API and ABI breaking changes
No API or ABI changes. This change only affects the CI/CD packaging
workflow.
# Expected complexity level and risk
1 - This PR only adds code signing to existing CI packaging. Risk is
limited to the Windows packaging step failing on tags; Linux and macOS
builds are unaffected.
# Testing
- [X] Tested via workflow dispatch on tag `test-signing-v0.0.1`
- [X] All three executables signed and verified successfully
- [X] Signature verification confirms certificate chain
- [X] Signed artifacts uploaded successfully
# Description of Changes
We run the "package CLI" job for every `master` commit, but I think we
basically never use those. Instead I added the work flow dispatch option
which can run as a one off if needed. (I didn't test it, but now that
it's added, we'll be able to fix it in a PR if needed).
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
None
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
**Note**: This change requires the addition of new entries in the
secrets to work properly. These should be added prior to this merging.
# Description of Changes
* Add a tag-only Windows signing job that runs on a self-hosted signing
runner.
* This is an alternative/separate code-path just for the signing job.
See **Alternatives Considered** for details.
* Skip the unsigned Windows matrix build on tags so signed artifacts are
the only Windows release outputs.
* Sign `spacetimedb-update.exe`, `spacetimedb-cli.exe`, and
`spacetimedb-standalone.exe` before packaging, then upload the signed
artifacts as usual.
# Alternatives Considered
**Inline signing in the existing Windows packaging step**. This was
rejected because it would require all Windows builds (including non-tag
builds) to run on the signing-capable runner or to install/signing
tooling on GitHub-hosted runners. The chosen approach isolates signing
to tag releases, avoids exposing credentials in standard builds, and
keeps routine CI behavior unchanged.
# API and ABI breaking changes
None
# Expected complexity level and risk
2 – low risk. CI-only change that adds a new signing job and preserves
existing artifact layout.
# Testing
- [X] None (Not running, workflow change only)
---------
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Our releases are currently broken because the machine that built the
release is based off of ubuntu 24.04. I've now changed it back to
`ubuntu-22.04` so that we don't have this issue.
```
boppy@geralt:~/clockwork/SpacetimeDB/crates/update$ curl -sSf https://install.spacetimedb.com | sh
Downloading installer...
/tmp/tmp.6i9sLQU0ff/spacetime-install: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /tmp/tmp.6i9sLQU0ff/spacetime-install)
boppy@geralt:~/clockwork/SpacetimeDB/crates/update$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy
```
# API and ABI breaking changes
None
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1 - we had fixed this before but we (meaning me) broket this again
recently.
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
I have not tested this myself but I know this fixes the issue because I
was the one who broke it.
# Description of Changes
CI is currently failing in a bunch of places since we tweaked the Rust
versions available in our CI runner, and it revealed that many of our
workflows don't set the default rust toolchain.
# API and ABI breaking changes
None. CI only.
# Expected complexity level and risk
1
# Testing
- [x] CI passes in this PR
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
This workflow change migrates us from docker container runners to the
new system which uses virtual machines via qemu. This solves a lot of
complexities around docker-in-docker and also allows us to easily run
windows VMs in the future.
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
None
# Expected complexity level and risk
0 - this only updates our workflow and has no impact on the code.
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] CI is passing
---------
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- This has 2 benefits:
1. `ubuntu-latest` recently changed to 24.04 instead of 22.04 so that
broke the last CLI on some systems. This will fix that issue.
2. Performance - this should build much much faster.
# API and ABI breaking changes
None
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
2 - if the CLI fails to build this might be why.
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
- [x] Tested via today's release:
https://github.com/clockworklabs/SpacetimeDB/actions/runs/19550648024/job/55980960439
John Detter