clean-architecture-backend-template/.github/workflows/fileserver-certification.yml

name: fileserver-certification

# The certification a release must clear. Its job list is deliberately the same shape as the support
# matrix: nothing may be advertised at a support level whose evidence job is absent here.
#
# Named "certification", not "release", and the name is the point. This workflow proves a storage
# topology, a support matrix and a telemetry redaction claim. It deploys nothing and holds no cluster
# credential. Calling it `fileserver-release.yml` read as if GitHub Actions released the fileserver,
# which is the CI/CD boundary this repository has now fixed in docs/ci-cd/boundary.md: GitHub Actions
# tests, scans and publishes artifacts; Argo CD deploys.
#
# It used to be workflow_dispatch only, which made that sentence false: the four jobs below are the
# only place the fileserver support matrix, the PVC manifest and the telemetry redaction proof are
# checked, and a release tag reached none of them unless somebody remembered to press a button.
#
# `v*` is the only release tag. The adapter-scoped `fileserver-v*` pattern is gone: this repository
# has one deployable unit (app-bootstrap), so an adapter-scoped tag could only ever run a subset of
# the release gates and call the result a release — the tag-namespace split that release.yml exists
# to end.
#
# These four jobs stay in their own file, and not in release.yml, for one mechanical reason:
# FileserverDocumentationCoverageTest reads job ids out of `.github/workflows/fileserver-*.yml` and
# requires every `fileserver-...` job docs/fileserver/support-matrix.md names to be defined in one
# of them. Renaming the file or moving these jobs needs that document changed in the same change.

on:
  push:
    tags:
      - "v*"
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: false

jobs:
  fileserver-full-verification:
    runs-on: ubuntu-latest
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # actions/checkout@v4.2.2
      - uses: ./.github/actions/setup-gradle-java
      - name: Run the architecture-wide dependency and module verification
        working-directory: src
        run: >-
          ./gradlew
          :verifyCleanArchitectureDependencies

          --stacktrace
      - name: Run the complete fileserver suite across every leaf
        working-directory: src
        run: >-
          ./gradlew
          :application-core:check
          :adapter:inbound:web:check
          :adapter:outbound:fileserver:check

          --stacktrace

  fileserver-documentation-gate:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # actions/checkout@v4.2.2
      - uses: ./.github/actions/setup-gradle-java
      - name: Prove every support claim maps to a job and every endpoint is documented
        working-directory: src
        run: >-
          ./gradlew
          :app-bootstrap:test --tests '*FileserverDocumentationCoverageTest'

          --stacktrace

  fileserver-pvc-certification:
    runs-on: ubuntu-latest
    timeout-minutes: 45
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # actions/checkout@v4.2.2
      # This job checks the manifest, and only the manifest. It deliberately does not apply anything
      # to a cluster.
      #
      # There used to be a second step here that applied the job to a release cluster when
      # secrets.FILESERVER_PVC_KUBECONFIG was set and `exit 0`-ed with a ::warning:: when it was
      # not. With no secret configured — which is every fork of this template and was this
      # repository — the step printed a warning and the job went green under the name
      # "fileserver-pvc-certification", so a release read as ReadWriteOnce-certified against a
      # cluster nothing had ever touched. It also wrote a `certified` output that no job, step or
      # script in this repository read.
      #
      # The cluster result comes from an operator running infra/fileserver/kubernetes/
      # pvc-certification-job.yaml against a real cluster and recording it in
      # docs/fileserver/storage-certification.md. That is registered as
      # docs/fileserver/storage-certification.md, and the absence of a cluster result is stated
      # there rather than hidden behind a green check.
      - name: Check the certification manifest still says what the claim depends on
        run: |
          set -euo pipefail
          manifest=infra/fileserver/kubernetes/pvc-certification-job.yaml
          test -f "$manifest"
          grep -q 'kind: PersistentVolumeClaim' "$manifest"
          grep -q 'kind: Job' "$manifest"
          # ReadWriteMany is explicitly not claimed; a manifest that quietly widened the access
          # mode would certify a topology the support matrix says is uncertified.
          grep -q 'ReadWriteOnce' "$manifest"
          ! grep -q 'ReadWriteMany' "$manifest"

  fileserver-sensitive-telemetry-scan:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # actions/checkout@v4.2.2
      - uses: ./.github/actions/setup-gradle-java
      - name: Prove telemetry carries no filename, path, or raw identifier
        working-directory: src
        run: >-
          ./gradlew
          :application-core:test --tests '*FileserverObservabilityTest'

          --stacktrace