GitHub Actions: generate a release-note image with the Sume Images API

To generate a release image from GitHub Actions, trigger on release: published, store your Sume key as a repository secret, call POST https://api.sume.com/v1/images with curl, pull data[0].url out with jq, download the file and upload it as an artifact. The whole job is about a dozen lines, and the only branch you must handle is the 202 that a slow image returns instead of the body.

Keep the model cheap for this job. A release card does not need a four-image batch at 4K, so send one image at the default size and a model whose list price you checked in GET /v1/images/models/{id}/endpoints.

What does each step do?

What is the workflow?

Save it as .github/workflows/release-image.yml. The release name goes into the prompt through an environment variable, not by string-splicing it into the script.

name: release-image
on:
  release:
    types: [published]
jobs:
  image:
    runs-on: ubuntu-latest
    env:
      NAME: ${{ github.event.release.name }}
      SUME_API_KEY: ${{ secrets.SUME_API_KEY }}
    steps:
      - name: Generate
        run: |
          body=$(jq -n --arg p "Clean abstract banner for a software release called $NAME" \
            '{model:"bytedance-seed/seedream-4.5",prompt:$p,aspect_ratio:"16:9"}')
          curl -sS https://api.sume.com/v1/images \
            -H "Authorization: Bearer $SUME_API_KEY" \
            -H "Content-Type: application/json" -d "$body" -o resp.json
          url=$(jq -er '.data[0].url' resp.json)
          curl -sSL "$url" -o release.png
      - uses: actions/upload-artifact@v4
        with:
          name: release-image
          path: release.png

What about slow or failed generations?

jq -e makes the step fail when .data[0].url is missing, which covers both the 202 job envelope and an error body. Sume bills completed generations in full and does not bill failed ones, so a failed run costs nothing, but a rerun of a successful job generates and bills a new image. Do not wire the workflow to rerun automatically on failure without that in mind.

If you want the release image in the release itself, add a step that attaches release.png with the GitHub CLI after you have looked at it; unattended publishing of generated art is a choice to make deliberately.

Should the key be a secret or a variable?

A secret. The workflow above reads it through an environment variable on the job, so it is not printed unless you echo it, and the key should be one you can revoke without touching other systems. Use a key you create for this repository only.