NeuralTrust Shared Workflows

Reusable GitHub Actions workflows for the NeuralTrust organization.

Every repo follows the same standardized pipeline:

┌──────────────┐ ┌────────────────────────────────────────────────────────────────┐
│ Push develop │────▶│ deploy.yml → build + image scan + kustomize + Slack notify │──▶ Dev
└──────────────┘ └────────────────────────────────────────────────────────────────┘
┌──────────────┐ ┌──────────────────────────────────────────────────────────────┐
│ PR → main │────▶│ ci.yml → Tests + SAST/security + metadata validation │
└──────────────┘ └──────────────────────────────────────────────────────────────┘
┌──────────────┐ ┌──────────────────────────────────────────────────┐
│ Push main │────▶│ auto-release.yml → AI Semver Bump → GitHub Release│
└──────────────┘ └────────────────────────┬─────────────────────────┘
 │ triggers
 ┌─────────────────────────▼──────────────────────────────────────┐
 │ release.yml → Smart Release (promote or rebuild) │
 │ │
 │ develop→main PR? ──YES──▶ SCAN → PROMOTE (crane copy) │──▶ Prod
 │ hotfix/direct? ──YES──▶ REBUILD → SCAN │──▶ Prod
 │ │
 │ Scan blocks CRITICAL/HIGH fixable CVEs (see image-scan.yml) │
 └────────────────────────────────────────────────────────────────┘
┌──────────────┐ ┌──────────────────────────────────────────────────┐
│ Weekly │────▶│ Dependabot → dependency update PRs (auto) │
└──────────────┘ └──────────────────────────────────────────────────┘

Important: Using squash merge for develop → main causes history divergence — the next comparison will show old commits even though their content was already merged. Always use "Create a merge commit" when merging develop into main.

Is your dev and prod registry in the same GCP project?
│
├─ NO (different projects) ← most NeuralTrust services
│ │
│ │ How many Docker images?
│ │
│ ├─ 1 image → release-promote.yml (smart: promote + rebuild fallback)
│ │
│ └─ 2+ images → multi-image-release-promote.yml
│
└─ YES (same project)
 │
 └─ 2+ images → multi-image-release.yml

release-promote.yml — The recommended release workflow. Automatically detects the best strategy:

Before any prod tag is applied or kustomization is updated, the release image is scanned for fixable CRITICAL/HIGH CVEs. A failure blocks the release and sends a Slack alert.

Dev deploys use the same scanner with block_vulnerability_findings: true. HIGH/CRITICAL findings fail the scan job (and the parent run), but kustomize only needs the build, so develop still ships.

1. Queries the GitHub API for PRs associated with the release commit
2. If a merged PR from develop → main is found:
   • Gets the develop branch tip SHA from the PR
   • Verifies the dev image exists in the dev registry (by commit SHA)
   • If found → promote (crane copy)
   • If not found → falls back to rebuild
3. If no develop→main PR → rebuild (hotfix path)

release (detect strategy + build if hotfix)
 │
 ▼
scan (Trivy — blocks on fixable CRITICAL/HIGH)
 │
 ├─ promote ──▶ promote-copy (crane dev → prod)
 │
 └─ rebuild ──▶ (promote-copy skipped)
 │
 ▼
update-kustomization + Slack notify

• Zero build time — image copy takes ~10 seconds vs minutes for a full build
• Byte-identical binary — what was tested in dev is exactly what runs in prod
• Scan-before-promote — prod tags are only applied after the dev image passes the vulnerability gate
• Version injection via ConfigMap — APPLICATION_VERSION is set in config.env, picked up by kustomize configMapGenerator, and overrides the build-time value at runtime

# .github/workflows/release.yml
name: Release
on:
 release:
 types: [published]
permissions:
 contents: write
 id-token: write
jobs:
 release:
 uses: NeuralTrust/workflows/.github/workflows/release-promote.yml@main
 with:
 image_name: my-service
 gcp_project_id: ${{ vars.PROD_GCP_PROJECT_ID }}
 dev_gcp_project_id: ${{ vars.DEV_GCP_PROJECT_ID }}
 secrets:
 WIF_PROVIDER: ${{ secrets.PROD_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.PROD_WIF_SERVICE_ACCOUNT }}
 GH_TOKEN: ${{ secrets.GH_TOKEN }}

With build args (used only for the rebuild/hotfix fallback):

jobs:
 release:
 uses: NeuralTrust/workflows/.github/workflows/release-promote.yml@main
 with:
 image_name: my-service
 gcp_project_id: ${{ vars.PROD_GCP_PROJECT_ID }}
 dev_gcp_project_id: ${{ vars.DEV_GCP_PROJECT_ID }}
 build_args: |
 VERSION=${{ github.event.release.tag_name }}
 GIT_COMMIT=${{ github.sha }}
 secrets:
 WIF_PROVIDER: ${{ secrets.PROD_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.PROD_WIF_SERVICE_ACCOUNT }}
 BUILD_SECRETS: |
 GITHUB_TOKEN=${{ secrets.GH_TOKEN }}
 GH_TOKEN: ${{ secrets.GH_TOKEN }}
 SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

multi-image-release-promote.yml — Same smart promote/rebuild logic for multi-image services.

jobs:
 release:
 uses: NeuralTrust/workflows/.github/workflows/multi-image-release-promote.yml@main
 with:
 images: |
 [
 {"name": "my-service", "target": "api"},
 {"name": "my-service-cli", "target": "cli"}
 ]
 kustomize_images: |
 [
 {"kustomize_name": "my-service", "image_name": "my-service"},
 {"kustomize_name": "my-service-cli", "image_name": "my-service-cli"}
 ]
 gcp_project_id: ${{ vars.PROD_GCP_PROJECT_ID }}
 dev_gcp_project_id: ${{ vars.DEV_GCP_PROJECT_ID }}
 commit_message_prefix: my-service
 secrets:
 WIF_PROVIDER: ${{ secrets.PROD_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.PROD_WIF_SERVICE_ACCOUNT }}
 GH_TOKEN: ${{ secrets.GH_TOKEN }}
 SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Detection runs once; each image is released in parallel via a matrix job. Per image:

release (detect strategy + build if rebuild) → scan (image-scan.yml) → promote-copy → update-kustomization

Each image is scanned for fixable CRITICAL/HIGH CVEs before crane copy or kustomize update — same gate as single-image release-promote.yml.

All services expose a /health endpoint returning:

{
 "status": "healthy",
 "version": "v1.2.3",
 "time": "2026年02月07日T20:06:41Z"
}

The version flows through two mechanisms:

In production, the ConfigMap env var overrides the Dockerfile value because Kubernetes env vars take precedence.

Go — init() function reads from env, overriding ldflags:

func init() {
 if v := os.Getenv("APPLICATION_VERSION"); v != "" {
 Version = v
 }
}

Python — reads from env directly:

app_version = os.environ.get("APPLICATION_VERSION", "unknown")

Node.js — reads from env directly:

version: process.env.APPLICATION_VERSION || 'unknown'

All deploy/release workflows automatically update APPLICATION_VERSION in the overlay's config.env:

• Dev deploy: APPLICATION_VERSION=<commit-sha>
• Prod release: APPLICATION_VERSION=<release-tag> (e.g., v1.2.3)

The kustomize configMapGenerator picks this up, regenerates the ConfigMap with a new hash suffix, and Kubernetes triggers a rollout.

ai-release-bump.yml — Analyzes commits since the last release using OpenAI and determines the appropriate semver bump:

• MAJOR — incompatible API changes, breaking changes
• MINOR — new features, backward-compatible functionality
• PATCH — bug fixes, docs, refactoring, dependency updates

Then creates a GitHub Release with the new version tag. The release event triggers the repo's release.yml for deployment.

# .github/workflows/auto-release.yml
name: Auto Release
on:
 push:
 branches: [main]
permissions:
 contents: write
jobs:
 release:
 uses: NeuralTrust/workflows/.github/workflows/ai-release-bump.yml@main
 secrets:
 OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
 GH_TOKEN: ${{ secrets.GH_TOKEN }}
 SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

The workflow creates a minimal GitHub Release body:

• What changed — bump type and AI reason
• Commits — list since the previous tag

It does not append installation instructions, container image tables, or an AI semver footer. Repos that need those (e.g. neuraltrust-platform) extend the release in a follow-up workflow (publish-chart.yml appends Container images and Installation).

If release creation fails (image-scan gate, missing dev image, publish error, or bump failure), the workflow posts a Slack message with the reason. Pass SLACK_WEBHOOK_URL from the caller; without it the job still fails and writes the reason to the step summary.

The bump-guard skips this workflow when the head commit message starts with:

• chore: bump version to ... — this workflow's own version bump commit.
• docs(changelog): — the prefix historically used by changelog-feed automation.

If you configure additional automated commits that push to main, prefix them similarly so they don't retrigger the release pipeline.

Important: GH_TOKEN must be a PAT (not GITHUB_TOKEN) so the created release event can trigger other workflows.

tests.yml — Generic test runner supporting multiple languages with optional service containers.

Go lint installs the pinned golangci_version from source with the selected language_version toolchain. This avoids running a prebuilt linter compiled by an older Go release against code that uses a newer language or standard-library surface.

Callers that need a temporary Go build experiment can set go_experiment; the value is exported as GOEXPERIMENT in both the lint and test jobs. Leave it empty for the toolchain default.

Start service containers with health checks and auto-exported env vars:

# Minimal (Go)
jobs:
 test:
 uses: NeuralTrust/workflows/.github/workflows/tests.yml@main
 with:
 language: go
 language_version: '1.27'

# Split tests (recommended pattern — lint only once, services only where needed)
jobs:
 unit-tests:
 uses: NeuralTrust/workflows/.github/workflows/tests.yml@main
 with:
 language: go
 language_version: '1.27'
 go_private_modules: true
 lint_enabled: true
 coverage_enabled: true
 test_command: |
 go test -v -race -coverprofile=coverage.txt -covermode=atomic ./internal/...
 setup_commands: |
 cp .env.example .env
 secrets:
 GH_TOKEN: ${{ secrets.GH_TOKEN }}
 integration-tests:
 uses: NeuralTrust/workflows/.github/workflows/tests.yml@main
 with:
 language: go
 language_version: '1.27'
 go_private_modules: true
 lint_enabled: false
 postgres_enabled: true
 postgres_db: my_app
 redis_enabled: true
 test_command: |
 go test -v -race ./tests/integration
 secrets:
 GH_TOKEN: ${{ secrets.GH_TOKEN }}
 TEST_SECRETS: |
 OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}

# Python with Kafka + PostgreSQL
jobs:
 test:
 uses: NeuralTrust/workflows/.github/workflows/tests.yml@main
 with:
 language: python
 language_version: '3.12'
 postgres_enabled: true
 kafka_enabled: true
 coverage_enabled: true
 coverage_file: coverage.xml

Service inputs:

Secrets:

The workflow runs two parallel jobs:

1. Lint — Language-specific linting (skipped if lint_enabled: false)
2. Test — Service startup + setup_commands + test execution (skipped if test_enabled: false)

sast.yml — Multi-layered security scanning with universal tools and language-specific SAST:

Universal (all repos):

Language analysis (opt-in per language):

# Go projects
jobs:
 security:
 uses: NeuralTrust/workflows/.github/workflows/sast.yml@main
 with:
 gosec_enabled: true
 govulncheck_enabled: true

govulncheck is blocking when enabled. By default it reads the Go toolchain from go.mod, scans ./..., and installs the pinned scanner version. Consumers with a container/toolchain version newer than their go.mod directive can set govulncheck_go_version explicitly so CI scans with the production toolchain. Private-module consumers must also set go_private_modules: true and pass GH_TOKEN.

# Python projects
jobs:
 security:
 uses: NeuralTrust/workflows/.github/workflows/sast.yml@main
 with:
 bandit_enabled: true
 bandit_args: '-r src/ -ll -x tests'

# Node projects
jobs:
 security:
 uses: NeuralTrust/workflows/.github/workflows/sast.yml@main
 with:
 njsscan_enabled: true

We don't have GitHub Advanced Security, so the Security tab / code scanning is unavailable on private repos. sast.yml therefore does not push SARIF to the Security tab. Instead:

• Job log — the Trivy table scan prints findings inline (this is also the blocking gate, via trivy_exit_code).
• Step summary — a short markdown summary per scanner.
• Run artifact — the full SARIF is saved as the trivy-sast-sarif artifact (7-day retention), downloadable from the run's Artifacts section.

No special permissions are required — contents: read is enough:

permissions:
 contents: read
jobs:
 security:
 uses: NeuralTrust/workflows/.github/workflows/sast.yml@main

Older callers that still grant security-events: write / actions: read for the (removed) Security-tab upload are harmless — those scopes are simply unused now and can be dropped.

seo-check.yml — Fast static scan via scripts/seo-static-audit.mjs (metadata, robots / sitemap routes, common gaps). See workflow file header for workflow_call inputs.

Example static site repo (e.g. web-public .github/workflows/site.yml): on PR — static seo-check.yml plus bundle npm run build:budget in parallel; on push to main — seo-live-url.yml when repo variable BASE_URL is set. Copy site.yml into other repos and adjust app_roots / scripts as needed.

seo-live-url.yml — curl homepage, optional robots.txt + sitemap HEAD, then seo-live-content-audit.mjs: parse sitemap(s), validate <loc> URLs (scheme/host vs base_url), sample HEAD/GET on up to N URLs, check robots.txt for Sitemap: lines, and on homepage + Lighthouse paths audit H1, <link rel="canonical">, and application/ld+json (valid JSON). Then Lighthouse SEO on base_url. Inputs: content_audit_enabled, content_audit_max_url_checks, content_audit_strict. Set repository variable BASE_URL; job skipped when unset.

docker-build-deploy.yml — Builds a single Docker image with COMMIT_SHA tags, updates kustomization and config.env, and sends Slack notifications.

# .github/workflows/deploy.yml
name: Build & Deploy
on:
 push:
 branches: [develop]
permissions:
 contents: write
 id-token: write
jobs:
 deploy:
 uses: NeuralTrust/workflows/.github/workflows/docker-build-deploy.yml@main
 with:
 image_name: my-service
 gcp_project_id: ${{ vars.DEV_GCP_PROJECT_ID }}
 secrets:
 WIF_PROVIDER: ${{ secrets.DEV_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.DEV_WIF_SERVICE_ACCOUNT }}
 GH_TOKEN: ${{ secrets.GH_TOKEN }}

1. Builds Docker image with tags: COMMIT_SHA, latest, cache
2. Injects APP_VERSION=<commit-sha> as a build arg
3. Scans the pushed image via image-scan.yml (CRITICAL/HIGH; scan job fails on findings, deploy is not gated)
4. Updates kustomization.yaml (image tag) and config.env (APPLICATION_VERSION) in parallel with the scan
5. Commits and pushes overlay updates (deploy workflows use paths-ignore: k8s/** so this does not retrigger builds)
6. Sends Slack notification

multi-image-deploy.yml — Matrix-based parallel build of multiple images + kustomization update.

jobs:
 deploy:
 uses: NeuralTrust/workflows/.github/workflows/multi-image-deploy.yml@main
 with:
 images: '[{"name":"api","target":"api"},{"name":"worker","target":"worker"}]'
 kustomize_images: '[{"kustomize_name":"api","image_name":"api"}]'
 gcp_project_id: ${{ vars.DEV_GCP_PROJECT_ID }}
 secrets:
 WIF_PROVIDER: ${{ secrets.DEV_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.DEV_WIF_SERVICE_ACCOUNT }}
 GH_TOKEN: ${{ secrets.GH_TOKEN }}

multi-image-release.yml — Always rebuilds. Use multi-image-release-promote.yml instead.

python-publish.yml — Builds a Python package (wheel + sdist) and publishes it to a GCP Artifact Registry Python repository. Supports both uv and poetry build tools.

# Using uv (default) — e.g., TrustTest
jobs:
 publish:
 uses: NeuralTrust/workflows/.github/workflows/python-publish.yml@main
 with:
 gcp_project_id: ${{ vars.PROD_GCP_PROJECT_ID }}
 secrets:
 WIF_PROVIDER: ${{ secrets.PROD_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.PROD_WIF_SERVICE_ACCOUNT }}

# Using poetry — e.g., internal-sdk
jobs:
 publish:
 uses: NeuralTrust/workflows/.github/workflows/python-publish.yml@main
 with:
 gcp_project_id: ${{ vars.PROD_GCP_PROJECT_ID }}
 build_tool: poetry
 python_version: '3.10'
 secrets:
 WIF_PROVIDER: ${{ secrets.PROD_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.PROD_WIF_SERVICE_ACCOUNT }}

Python library repos follow a slightly different pattern from Docker-based services:

┌──────────────┐ ┌──────────────────────────────────────────────────────┐
│ Push develop │────▶│ publish-dev.yml → python-publish → DEV AR registry │
└──────────────┘ └──────────────────────────────────────────────────────┘
┌──────────────┐ ┌──────────────────────────────────────────────────────┐
│ PR → main │────▶│ ci.yml → Lint + SAST/security + metadata validation │
└──────────────┘ └──────────────────────────────────────────────────────┘
┌──────────────┐ ┌──────────────────────────────────────────┐
│ Push main │────▶│ auto-release.yml → AI Semver Bump + GitHub│
│ │ │ Release + update pyproject.toml version │
└──────────────┘ └─────────────────┬────────────────────────┘
 │ triggers
 ┌──────────────────▼──────────────────────────────────┐
 │ release.yml → python-publish → PROD AR registry │
 └────────────────────────────────────────────────────┘

smoke-test.yml — Post-deploy health check that polls a service endpoint waiting for the expected version. Designed for FluxCD/GitOps where deployment is async.

# Smoke test after dev deploy
jobs:
 deploy:
 uses: NeuralTrust/workflows/.github/workflows/docker-build-deploy.yml@main
 with:
 image_name: my-service
 gcp_project_id: ${{ vars.DEV_GCP_PROJECT_ID }}
 secrets:
 WIF_PROVIDER: ${{ secrets.DEV_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.DEV_WIF_SERVICE_ACCOUNT }}
 GH_TOKEN: ${{ secrets.GH_TOKEN }}
 smoke-test:
 needs: deploy
 uses: NeuralTrust/workflows/.github/workflows/smoke-test.yml@main
 with:
 health_url: https://api.dev.example.com/health
 expected_version: ${{ github.sha }}
 environment: dev
 secrets:
 SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

1. Waits initial_delay seconds (gives FluxCD time to detect the kustomization change)
2. Polls health_url every poll_interval seconds
3. If response contains expected_version → SUCCESS
4. After timeout_minutes, checks one final time:
   • Service responds but version doesn't match → WARNING
   • Service doesn't respond → PROBLEM
5. Sends Slack notification for WARNING and PROBLEM outcomes

e2e-playwright.yml — Runs Playwright tests from the shared e2e-tests Docker image against a deployed service, publishes results to Allure, and uploads HTML/Allure artifacts.

# After dev deploy
jobs:
 deploy:
 uses: NeuralTrust/workflows/.github/workflows/docker-build-deploy.yml@main
 # ...
 e2e:
 needs: deploy
 uses: NeuralTrust/workflows/.github/workflows/e2e-playwright.yml@main
 with:
 service: app
 base_url: https://app.dev.neuraltrust.ai
 expected_version: ${{ github.sha }}
 e2e_tests_channel: prod
 image_tag: latest
 secrets:
 TWINGATE_SERVICE_KEY: ${{ secrets.TWINGATE_SERVICE_KEY }}
 ALLURE_USER: ${{ secrets.ALLURE_USER }}
 ALLURE_PASS: ${{ secrets.ALLURE_PASS }}
 PROD_WIF_PROVIDER: ${{ secrets.PROD_WIF_PROVIDER }}
 PROD_WIF_SERVICE_ACCOUNT: ${{ secrets.PROD_WIF_SERVICE_ACCOUNT }}
 DEV_WIF_PROVIDER: ${{ secrets.DEV_WIF_PROVIDER }}
 DEV_WIF_SERVICE_ACCOUNT: ${{ secrets.DEV_WIF_SERVICE_ACCOUNT }}
 E2E_SECRETS_JSON: ${{ secrets.E2E_APP_SECRETS_JSON }}

Stable vs experimental tests: base_url (dev or prod app) is independent of the test image. By default callers use e2e_tests_channel: prod and pull latest from the prod Artifact Registry (built from e2e-tests main). Set e2e_tests_channel: develop (repo var E2E_TESTS_CHANNEL in app) to validate in-flight test changes from the dev registry (built from e2e-tests develop).

# app — opt into experimental tests while still hitting dev URL
with:
 base_url: https://app.dev.neuraltrust.ai
 e2e_tests_channel: develop # or vars.E2E_TESTS_CHANNEL=develop
 image_tag: latest

Pass non-secret service-specific E2E settings via e2e_vars_json; pass credentials through E2E_SECRETS_JSON or the individual E2E secrets.

Container images are scanned with Trivy via image-scan.yml. Deploy and release workflows call it automatically; you can also invoke it standalone.

Both modes scan for CRITICAL,HIGH severity and count only fixable CVEs (ignore_unfixed: true).

image-scan.yml — Pulls an image from Artifact Registry, scans OS packages and application dependencies, prints findings to the job log, and saves the SARIF as a downloadable run artifact.

Findings are always printed as a table in the job log and the blocking gate lives there (exit_code), so a blocked promote always shows which CVEs caused it. The SARIF report is saved as the trivy-image-sarif run artifact (7-day retention) — there's no Security-tab upload (we don't have GitHub Advanced Security). Only contents: read + id-token: write (to pull the image) are needed.

jobs:
 scan:
 uses: NeuralTrust/workflows/.github/workflows/image-scan.yml@main
 permissions:
 contents: read
 id-token: write # GCP WIF auth to pull the image
 with:
 image_ref: europe-west1-docker.pkg.dev/my-proj/nt-docker/my-svc:abc123
 exit_code: '1' # '0' = warn, '1' = block
 secrets:
 WIF_PROVIDER: ${{ secrets.DEV_WIF_PROVIDER }}
 WIF_SERVICE_ACCOUNT: ${{ secrets.DEV_WIF_SERVICE_ACCOUNT }}

Image scans use scanners: vuln by default so prod gates block only on fixable CVEs, not Trivy secret hits in third-party packages (e.g. masked tokens in trusttest dataset YAML). Repository secret detection stays in sast.yml / Gitleaks.

Add a .trivyignore file at the repo root (same convention as sast.yml) to suppress accepted CVE findings. Both deploy and release scans auto-detect it.

Deploy and release workflows send Slack notifications on success or failure.

Auto-release (ai-release-bump.yml) posts only on failure, with the reason the GitHub Release was not created (image-scan gate, missing dev image, publish error, or bump failure).

Smart release notifications include the strategy used:

• "promoted from dev" (for develop→main releases)
• "rebuilt (hotfix)" (for direct pushes)
• "Blocked by image scan" (fixable CRITICAL/HIGH CVEs found — see the job log / trivy-image-sarif artifact)

To enable:

1. Create a Slack Incoming Webhook
2. Add it as an organization secret: SLACK_WEBHOOK_URL
3. Callers using secrets: inherit get notifications automatically

If the secret is not set, the notification step is silently skipped.

All repos include a dependabot.yml that creates automated PRs for dependency updates:

PRs target the develop branch only. Since all changes must be tested before promotion to main, dependency updates follow the same flow: merged into develop → tested → promoted via PR to main. Dependabot PRs trigger the standard CI pipeline (tests + SAST/security + metadata validation), so safe updates follow the same review path as other changes.

Security updates are different. GitHub Dependabot security PRs always open against the repository default branch (main in this org). There is no organization-level setting and no dependabot.yml key that can change that.

dependabot-retarget.yml is the org-wide workaround: twice a day at 00:00 and 12:00 UTC (and workflow_dispatch) it searches NeuralTrust for open Dependabot PRs against main and moves them onto develop when that branch exists. Repos without develop stay on main. Dependabot rebase can reset the base back to main, which is why the job is scheduled rather than one-shot.

Every service still needs a per-repo .github/dependabot.yml with target-branch: develop so version updates (weekly bumps) open against develop rather than main.

Because every repo in the org consumes these reusable workflows and composite actions, a mistake here breaks pipelines org-wide. This repo therefore guards its own Actions surface:

scripts/workflow-hygiene.py enforces two rules on every workflow that exposes workflow_call. Run it locally before pushing:

python3 scripts/workflow-hygiene.py

Self-triggered workflows in this repo (e.g. workflows-ci.yml, scorecard.yml) are not covered by the concurrency rule — they aren't consumed by other repos and set their own concurrency directly.

zizmor is a blocking gate, but is ratcheted rather than all-or-nothing. The repo carries a backlog of template-injection findings where ${{ inputs.* }} is interpolated directly into run: blocks. Those counts are pinned per file in .github/zizmor-baseline.json; a PR fails when any file goes above its baseline. New findings block, fixes are always allowed.

Disabling the audit outright was rejected: it would hide genuinely new findings. A blanket --fix was also rejected, since it rewrites expansions inside quoted heredocs where shell expansion never happens.

# reproduce the gate locally
uvx zizmor@1.25.2 --config .github/zizmor.yml --no-exit-codes --format json . > zizmor.json
python3 scripts/zizmor-ratchet.py zizmor.json
# after fixing findings, lower the baseline so the fix can't regress
python3 scripts/zizmor-ratchet.py zizmor.json --update

To work the backlog down, move the interpolation into an env: block and use shell expansion (${VAR}, not ${{ env.VAR }}), then re-run with --update.

To enable the gates fully (recommended), turn on branch protection for main with: require PR review, require "Workflows CI" status check, and require review from Code Owners.

Run the setup script to configure all GCP and GitHub infrastructure in one go:

cd workflows
chmod +x setup-pipeline.sh
./setup-pipeline.sh

The script handles:

1. GCP Workload Identity Federation (WIF) pools and OIDC providers for dev and prod
2. GCP Service Accounts with Artifact Registry writer permissions
3. Cross-project read access (prod SA → dev registry) for the image promote strategy
4. GitHub org-level variables (DEV_GCP_PROJECT_ID, PROD_GCP_PROJECT_ID)
5. GitHub org-level secrets (WIF providers, service accounts, tokens)

Prerequisites: gcloud, gh, and jq must be installed and authenticated.

Organization-level variables (not sensitive):

Organization-level secrets:

Note: Callers explicitly reference the correct org secret by name — deploy.yml uses DEV_* secrets, release.yml uses PROD_* secrets. The reusable workflows accept generic WIF_PROVIDER / WIF_SERVICE_ACCOUNT inputs and are unchanged.

Per-repo secrets (only where needed):

IAM requirements (for promote strategy):

The prod WIF service account needs read access to the dev Artifact Registry:

gcloud artifacts repositories add-iam-policy-binding nt-docker \
 --project=<DEV_GCP_PROJECT_ID> \
 --location=europe-west1 \
 --member="serviceAccount:<PROD_WIF_SA_EMAIL>" \
 --role="roles/artifactregistry.reader"

Run ./setup-pipeline.sh from the workflows repo to automate the full WIF + secrets setup.