Set up ReRune in CI/CD

The rerune-ci-demo repository installs CLI 1.0.13, pulls published English and German i18next files into a clean directory, validates three application keys, and builds a small static site. It saves the exact locale files with the build and can deploy that same artifact to GitHub Pages.

• Open rerune-ci-demo
• Full GitHub Actions workflow
• Open the deployed demo
• CLI setup, sync, and publication

1. Copy the demo repository, including .github/workflows/rerune-ci.yml and scripts/, into your GitHub repository. The workflow expects these files at the repository root and uses main as the default branch.
2. Create a ReRune project with English as the main language and German as a target language. Import the seed files as flat i18next resources, then review and publish welcome, save_book, and saved. Pull reads published values.
3. In GitHub Settings → Secrets and variables → Actions, add the repository variable RERUNE_PROJECT_ID with your 24-character project ID. Add RERUNE_API_KEY as a repository secret containing a personal API key whose user belongs to the project's organisation.

This read-only build needs organisation membership, not edit or publishing grants. Personal API keys follow the user's access. Use the API key for CLI sync; an OTA Publish ID is for SDK delivery.

The supplied install-rerune.sh pins CLI 1.0.13 on Linux x86_64, checks the archive and executable hashes, and adds the binary directory to GITHUB_PATH for later steps. Keep the pin and checksums together when upgrading.

prepare-rerune.py reads the project variable and writes rerune.json with the configuration below. The CLI resolves the literal ${RERUNE_API_KEY} reference at runtime. RERUNE_PROJECT_ID is an input to the example's Python script, not a native CLI environment override.

{
  "api_key": "${RERUNE_API_KEY}",
  "project_id": "<YOUR_24_CHARACTER_PROJECT_ID>",
  "languages": [
    { "code": "en", "name": "English", "main": true },
    { "code": "de", "name": "German", "main": false }
  ],
  "translations_path": "./build/l10n/",
  "translation_file_name": "translation.json",
  "platform": "i18next"
}

The script rejects a nonempty build/l10n directory and omits last_sync. Pull merges existing local files, so old local-only keys could otherwise survive into a build. Do not restore the output directory or mutated rerune.json from a cache. Keep rerune.json and .env out of the build artifact. Add new languages explicitly to both configuration and application validation.

With the demo scripts copied into your repository, the build job runs the steps below. Run the commands from the directory containing rerune.json. The API key is passed only to the pull step.

- name: Install pinned ReRune CLI
  run: bash scripts/install-rerune.sh

- name: Prepare project configuration
  env:
    RERUNE_PROJECT_ID: ${{ vars.RERUNE_PROJECT_ID }}
  run: python3 scripts/prepare-rerune.py

- name: Pull published translations
  env:
    RERUNE_API_KEY: ${{ secrets.RERUNE_API_KEY }}
  run: |
    set -euo pipefail
    : "${RERUNE_API_KEY:?Set the RERUNE_API_KEY repository secret}"
    rerune version
    rerune pull

- name: Validate application translation requirements
  run: python3 scripts/check-translations.py

- name: Build using the validated files
  run: python3 scripts/build-demo.py

check-translations.py validates the demo's required flat keys and simple i18next placeholders before the build. It is application code, not a built-in ReRune validation command or a general ICU checker. Replace it with checks for your own keys, placeholders, localization generation, and application tests.

To try the failure path, publish only welcome and save_book in a dedicated demo project. The pull can succeed, but validation stops the build because saved is missing. Publish the reviewed missing key and rerun. A successful pull may be silent; its exit status and the following checks determine success.

build-demo.py writes the pages, exact pulled locale files, and a SHA-256 manifest into dist/. The workflow uploads that directory as an artifact. Pinning the CLI fixes the tool version, but published translations remain live inputs: the same Git commit can build different text later. Keep the artifact to identify exactly what the run used.

The demo runs on pushes to main and manual workflow dispatches from main. It does not run on pull requests, and publishing in ReRune does not automatically trigger it. For a translation-only change, open Actions → ReRune translations and demo build → Run workflow.

Leave Deploy the tested example off for the first run. Download the build artifact and inspect en.html and de.html. Run python3 test-example.py locally to check the scripts with synthetic fixtures; those tests do not contact ReRune.

For deployment, set the repository's GitHub Pages source to GitHub Actions, allow main in the github-pages environment, and run manually with Deploy the tested example enabled. The deploy job waits for the build and deploys its Pages artifact without pulling translations again. Only that job needs pages: write and id-token: write; the build uses contents: read.

For another CI provider, keep the same order: install a pinned CLI, inject credentials, prepare a fresh configuration, pull, validate, build, save the inputs, then deploy that artifact. Replace the GitHub-specific secret, artifact, and deployment steps with your provider's equivalents.

The demo build does not push or publish. rerune push updates drafts, can create missing configured languages, and merges using last_sync. Do not reuse the clean pull configuration as a source-authoritative push recipe or invent a timestamp to force local values to win. Multi-language pushes can partially succeed remotely.

For a separately reviewed publication workflow, use a user with publishing permission and the explicit unattended command below. Set RERUNE_PROJECT_ID and RELEASE_TAG in that job and provide its API-key-backed rerune.json. --all selects current ready drafts across the project. Replace it with repeated --key IDs to publish a smaller selection.

rerune publish --all --project "$RERUNE_PROJECT_ID" \
  --tag "$RELEASE_TAG" --yes --json > publish-result.json

Keep publish-result.json as a workflow artifact even if the command fails. Inspect skipped, warnings, and unprocessed results; exit 0 does not mean every draft changed. Without --yes, unattended EOF can cancel publication with exit 0. A build that pulled published text has not validated drafts released by a later publication.

Use OTA staging to review drafts in a test app before publication. Staging does not change what this CLI pull-based build downloads.