Vera

Gate pull requests on Vera tests with GitHub Actions

The vera-run action starts a Vera run from a workflow, waits for the result, and fails the job only on a blocking failure. A quarantined failure or a test that passed only on retry is annotated as a warning and listed in the job summary instead, so a flaky test cannot silently pass or noisily block.

What comes across

  • The action takes your Vera URL, a CI token and a project id, and optionally a single test, a suite, a named environment or a preview URL.
  • Quarantined failures and passed-on-retry tests become ::warning:: annotations and a job-summary table with a report link, not a red job.
  • Without preview-url, the action falls back to VERCEL_URL, DEPLOY_PRIME_URL or DEPLOY_URL, so the suite runs against each pull request’s preview deploy.
  • fail-on-flaky: 'true' makes a test that passed only on retry fail the job.
  • Outputs — status, report-url, passed, failed, quarantined-failed, passed-on-retry and healed — are available to later steps.
  • It gates exactly like the GitLab and Bitbucket templates: a test in Vera executes the action and the shell gate against the same canned responses and fails if their exit codes differ.

What does not

  • fail-on-healed is inert today: the run this action starts has no selector healer attached, so healed comes back 0 and the input cannot fail a job. It is kept so it takes effect the day CI runs can heal.
  • The CI API needs the Pro plan's api-access feature on Vera's cloud; a free workspace's token is refused there. Self-hosted installs have no billing and hold everything.
  • The action runs a fixed set: one test, one suite or the whole project. Running only the tests a pull request touches is a separate command, vera check.

How to set it up

  1. Mint a token under Settings → CI Tokens. The vera_… value is shown once, so store it as a secret straight away.
  2. Store the token as a repository secret (for example VERA_TOKEN), alongside your Vera URL.
  3. Add a job that uses the vera-run action with api-url, api-token and project — vendor actions/vera-run into .github/actions/vera-run if you are not referencing a published tag.
  4. Pass preview-url from your deploy step to test each pull request’s preview.
  5. Opt in to fail-on-flaky: 'true' on branches where a retry-flake should block.

Questions

Does a flaky test fail the GitHub Actions job?

Not by default. A test that passed only on retry is a warning annotation and a row in the job summary. Set fail-on-flaky: 'true' to make it fail the job.

Does a quarantined test failure block the merge?

No. A failed quarantined test produces a warning, not a red job. Quarantine is the escape hatch, and an escape hatch that can still fail the build is not one.

What does fail-on-healed do in GitHub Actions?

Nothing yet. A CI-started run has no selector healer, so healed is always 0 and the input cannot fail a job. It is kept so it takes effect once CI runs can heal.

Which Vera plan does the GitHub Action need?

Pro or above on Vera's cloud, because the action calls the CI API, which needs the api-access feature. Self-hosted installs have no billing and hold everything.

Read more

Start free