CI & GitHub Actions

The pattern

Run the CLI against your case directory. A non-zero exit fails the job, which fails the check, which blocks the merge — the same gate you already trust for unit tests, now covering release-critical integration behavior and flag proof.

name: Release-proof gate

on:
  pull_request:

jobs:
  release-proof:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "8.0.x"
      - run: dotnet build src/ReleaseTwin.Cli/ReleaseTwin.Cli.csproj -c Release --nologo
      - name: Run release-proof cases
        run: >
          dotnet run --project src/ReleaseTwin.Cli -c Release --no-build --
          cases/

Once a versioned CLI image is published, the build step goes away and the gate is a single line:

- run: docker run --rm -v "$PWD/cases:/workspace:ro" ghcr.io/OWNER/releasetwin/cli:VERSION

Credentials

• HTTP-only cases need nothing. Case files reference ${ENV_VAR}; set those from your CI's secret store.
• A flag-proof leg needs its flag source's credentials as job env — e.g. LAUNCHDARKLY_API_TOKEN: ${{ secrets.LAUNCHDARKLY_API_TOKEN }}.
• If you connect the hosted dashboard, add RELEASETWIN_API_TOKEN and RELEASETWIN_API_URL — run history and evidence then land on the dashboard for every CI run.

PR annotations

The integrations/github-action Action runs your cases and renders the result onto the pull request — a comment (updated in place on re-runs) with the pass/fail totals and flag-proof verdict, plus a ReleaseTwin check run you can make a required status check. It talks only to GitHub's own APIs with the workflow's GITHUB_TOKEN — no ReleaseTwin account. It is Apache-2.0, so you can fork and adapt it.

permissions:
  contents: read
  pull-requests: write
  checks: write

jobs:
  release-proof:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ernestoalejowitt22/ReleaseTwin/integrations/github-action@v1
        with:
          cases-path: cases
          image: ghcr.io/OWNER/releasetwin/cli:VERSION

The CLI still writes a machine-readable summary on its own with --summary-json <path> (or RELEASETWIN_SUMMARY_JSON) if you want to render it somewhere else.

Bitbucket, GitLab, and other CI

The GitHub Action is a convenience wrapper. The portable primitive is the non-zero exit code plus the --summary-json file — nothing about either is GitHub-specific. On Bitbucket Pipelines the gate is one step:

pipelines:
  pull-requests:
    '**':
      - step:
          name: Release-proof gate
          services: [docker]
          script:
            - >
              docker run --rm -v "$BITBUCKET_CLONE_DIR/cases:/workspace:ro" -v "$BITBUCKET_CLONE_DIR:/out"
              ghcr.io/OWNER/releasetwin/cli:VERSION /workspace --summary-json /out/releasetwin-summary.json
          artifacts:
            - releasetwin-summary.json

A non-zero exit fails the step and blocks the merge with no extra wiring. To render the summary as a Bitbucket PR comment, parse releasetwin-summary.json and POST it to the /2.0/repositories/{workspace}/{repo}/pullrequests/{id}/comments API — the same shape as the GitHub Action's render.mjs, which you can adapt.

Live example in this repo

.github/workflows/releasetwin-demo.yml runs the zero-credential HTTP case on every PR and on demand — a real, green release-proof gate you can copy. A passing run's step output:

$ dotnet run --project src/ReleaseTwin.Cli -c Release --no-build -- demo/quickstart/cases

PASS HTTP-DEMO-1
1 passed, 0 failed

Next

Case files for what each case can assert, or Hosted platform to send CI run history to the dashboard.