ubuntu-latest moves to 26.04: test your Sume workflow now

If a GitHub Actions workflow of yours calls the Sume API from a job that says runs-on: ubuntu-latest, the machine under it is about to change. GitHub's changelog says the ubuntu-latest label migrates from Ubuntu 24.04 to Ubuntu 26.04 gradually between October 19 and November 19, 2026 (read 2026-10-04). The cheap fix is a matrix that runs the same small Sume check on ubuntu-24.04 and ubuntu-26.04 this week, so you learn about a missing tool before a scheduled run does.

The Sume side of this is small. The API is plain HTTPS with one key header, so a workflow that only uses curl has very little that an image change can break. The risk sits in the shell glue around it: a jq filter, a Python helper, a pinned CLI download. This post is a checklist for finding that glue.

What GitHub says is changing

The changelog entry makes three statements worth acting on. The ubuntu-latest label moves to 26.04 in a rolling window, not on one day. The 26.04 image has updated and, in some cases, removed tools and tool versions compared with earlier images. And GitHub's advice is to test against ubuntu-26.04 before the migration, or pin to ubuntu-24.04 if you are not ready.

The entry does not list which tools changed; it points to the runner-images repository for the full software inventory. So this post does not guess at which package disappears. It shows a way to make your own workflow tell you.

A two-image smoke test for a Sume key

Sume documents GET /v1/me as the way to verify a key, and the authentication guide lists key verification as the step before revoking an old key. That makes it the right body for a smoke test: it is a read, it spends nothing, and it fails with a clear 401 if the secret is missing or wrong. Reads also have their own, much larger request budget than writes, so a weekly check will never compete with your submits.

The workflow below checks that curl exists on each image and then prints only the HTTP status. It deliberately avoids printing the response body, which carries key metadata you do not need in a log. Note the single x-api-key header: Sume rejects a request that carries both Authorization: Bearer and x-api-key with 401 unauthorized, so pick one and keep it.

name: sume-smoke
on:
  schedule:
    - cron: '17 6 * * 1'
  workflow_dispatch:
jobs:
  smoke:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-24.04, ubuntu-26.04]
    runs-on: ${{ matrix.os }}
    steps:
      - name: Sume key check
        env:
          SUME_API_KEY: ${{ secrets.SUME_API_KEY }}
        run: |
          set -eu
          command -v curl || { echo 'curl missing'; exit 1; }
          code=$(curl -sS -o /dev/null -w '%{http_code}' \
            https://api.sume.com/v1/me -H "x-api-key: $SUME_API_KEY")
          echo "GET /v1/me -> $code"
          test "$code" = 200

Where the real breakage tends to hide

A curl status check passing on both images tells you the network path and the secret are fine. It does not tell you your own helper steps survive. Add one line per tool your real job uses, in the same step, so the smoke test fails for the same reason the real job would:

Keep the paid part of the workflow out of the smoke test. If your real job submits a render, it should send an Idempotency-Key derived from the thing being rendered, so a re-run after a runner problem returns the original job instead of billing a second one. The post on re-running a workflow with idempotency keys covers that pattern.

• Any jq or python3 call that parses a Sume response: add command -v jq or python3 --version to the check.
• Any downloaded binary pinned by URL: confirm it still starts on 26.04.
• Any apt-get install line: run it on both images, since package names and versions can differ.
• Any path that assumed the old image's tool locations.

Pin or migrate

If the matrix is green on both images, leave ubuntu-latest alone and let it move. If 26.04 fails and you cannot fix it this month, pin runs-on: ubuntu-24.04 for that workflow, which is the other option GitHub names, and set yourself a reminder to revisit it. Either way the Sume calls themselves do not change: the endpoint, the key header and the status codes are the same on both images.

For a longer weekly check that also confirms the wallet can cover your next batch, add a read of GET /v1/balance, which Sume documents as the USD-denominated available balance. Both reads are covered in the API reference.