Review a promotion workflow and its release record.

Instruction: Identify the unsupported promotion, correct the workflow step and state the evidence required before production exposure.

Context:

A fictional team accepts external pull requests, which run isolated tests without deployment credentials. The following is a job excerpt from its trusted GitHub Actions deployment workflow. Checkout, registry authentication and runner setup are omitted. The reviewed deploy.sh ENV IMAGE_REF wrapper accepts a digest or tag and does not verify staging approval itself.

jobs:
  production:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Build production image
        run: docker build -t registry.example/orders:prod .
      - name: Push production image
        run: docker push registry.example/orders:prod
      - name: Deploy
        run: ./deploy.sh production registry.example/orders:prod
Release evidenceValue
Staging-tested commitc7e21f0 (display abbreviation)
Staging-approved imageregistry.example/orders@sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Staging configurationcfg-staging-17
New production push, same commitregistry.example/orders@sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Reviewed production configurationcfg-prod-9
Known compatible recovery artifact/configurationRecorded and available

These are full-length fictional digests. The same commit can resolve different build inputs. Explain whether the supplied production image is covered by the staging evidence.

Updated

Official answer available

Read the opening below, then unlock the full answer and practical guidance.

Staging tested digest A, but promotion rebuilt digest B. The same commit does not establish equivalent bytes, so the supplied evidence does not approve B...

Upgrade to view official answer

Related Questions