# Add to your existing release pipeline after its staging deployment is ready.
# Configure VERSARIAL_AUDIT_URL to a connected audit adapter implementing the
# request/response contract in release-audit.mjs. This template does not supply
# a Versarial audit service or a production deployment command.
name: Versarial release assessment

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  abuse-assessment:
    name: Versarial abuse assessment
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - name: Assess staging against release rules
        env:
          VERSARIAL_AUDIT_URL: ${{ vars.VERSARIAL_AUDIT_URL }}
          VERSARIAL_API_KEY: ${{ secrets.VERSARIAL_API_KEY }}
          STAGING_URL: ${{ vars.STAGING_URL }}
          RELEASE_SHA: ${{ github.sha }}
        run: node scripts/release-audit.mjs
      - name: Keep the assessment report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: versarial-assessment-${{ github.sha }}
          path: versarial-report.json
          if-no-files-found: ignore
          retention-days: 14

# For release enforcement:
# 1. Copy release-audit.mjs to scripts/release-audit.mjs.
# 2. Put abuse-assessment after your staging job using needs: [staging].
# 3. Make production depend on abuse-assessment using needs: [abuse-assessment].
# 4. Run that pipeline on your actual release trigger, not release.published.
# A published-release trigger would test after publication.
# For pull-request checks, use a separate trusted staging workflow and make
# this job a required status check. Fork pull requests cannot access secrets.