Show build and test status on the card

When the build is red the team wants to see it on the card, not in a second tab. This guide reports build and test status from your pipeline to Zuuna. It belongs to the Developer plan and works with any CI system that can make an HTTP call.

What you need

• The Developer plan — see pricing.
• An API token carrying the git:write scope, stored as a secret in your CI.
• Ideally already set up: linking commits to cards — then Zuuna finds the card on its own.

1. Prepare a token with git:write

In the developer console create a token with git:write and nothing else, then store it as a secret in your CI — in GitHub Actions under Settings → Secrets and variables → Actions. A CI runner needs no scope beyond this one.

2. Report the status from the pipeline

One call at the end of the job is enough. As a GitHub Actions step:

- name: Report build status to Zuuna
  if: always()
  run: |
    curl -sS -X POST https://app.zuuna.de/api/v1/git/checks \
      -H "Authorization: Bearer $ZUUNA_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "repo": { "remoteUrl": "'"$GITHUB_SERVER_URL/$GITHUB_REPOSITORY"'" },
        "checks": [{
          "name": "build",
          "status": "'"${{ job.status == 'success' && 'passing' || 'failing' }}"'",
          "sha": "'"$GITHUB_SHA"'",
          "branch": "'"${GITHUB_REF#refs/heads/}"'",
          "url": "'"$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID"'"
        }]
      }'
  env:
    ZUUNA_TOKEN: ${{ secrets.ZUUNA_TOKEN }}

if: always() is the important part — without it the pipeline reports only the green runs, which are precisely the ones nobody needs to be told about.

Allowed values for status: passing, failing, pending. Up to 1,000 check results fit in one call if you report several jobs together.

3. Understand how Zuuna finds the card

Zuuna looks for the card in this order: by commit SHA, branch or pull request, where a link already exists. If nothing matches, a card key in the branch name is used. This is why the post-commit hook from the first tutorial pays off: it creates the link everything else then orients itself by.

4. Check the card

The card now carries the check with its name, status and a link to the log — one click and you are in the right run. The status change also appears in the card's activity.

5. Keep re-runs clean

Re-running the same job overwrites the result of the same name rather than adding a second row. The card therefore always shows the current state, not a history of twelve attempts. If you want several checks tracked separately, give them different names — build, tests, lint.

Troubleshooting

• No check on the card. Usually Zuuna found no card: neither an existing link nor a card key in the branch name. Check both.
• 401 or 403. The token is missing, revoked, or lacks git:write.
• Only green runs arrive. if: always() is missing — the step is skipped when the job fails.
• The red build fires no automation. Check that a rule listens for "CI failed". And note that pending never fires anything.

Next steps

• Move cards automatically with git — react to a red build.
• The code graph — what shipped without a ticket.
• Create an API token and make your first call.