Deploy validated main images to development #34

Open
opened 2026-11-01 20:11:51 +00:00 by viacheslavshuka · 0 comments

Development should track validated main commits automatically. A passing pull request for another commit must not authorize deployment of the squashed result.

Scope

Publish the built image to the Forgejo container registry and deploy it through Dokploy. Use the existing runner flow and inspect the installed Dokploy API and routing behavior.

Acceptance criteria

  • The actual main commit passes all applicable required validation before deployment. The artifact record associates that commit, its image digest, and check results.
  • Dokploy pulls the selected image digest. It does not rebuild source. Web and available worker services use the same image and application version.
  • Apply the candidate's committed migrations before starting web or worker versions that need them. Serialize migration execution within the deployment.
  • Migration failure blocks rollout and leaves the existing compatible application running. Preserve migration failure evidence without automatically restoring the database.
  • Development uses separate databases, credentials, integrations, data, and notification destinations. It cannot read production participant data or send production notifications.
  • Failed validation leaves the current development deployment running. A raw push webhook cannot bypass the required checks.
  • Deployments serialize within the development environment. Superseded queued commits are skipped before deployment starts. An older deployment cannot overwrite a newer successful one.
  • CI correlates the asynchronous Dokploy request with its deployment result. An accepted API request alone cannot pass the job.
  • Completion requires readiness through the normal application entry point and the expected version and commit or image identity.
  • Cancellation, timeout, deployment error, failed readiness, and a healthy wrong build fail the deployment result. Failure evidence remains available.
  • Deployment credentials exist only in the trusted deployment job. Validation jobs cannot access production credentials, resources, or deployment privileges.

Validation

Use a disposable development target to exercise passing deployment, validation rejection, asynchronous failure, wrong identity, and superseded queue entries. Verify a failed check does not replace the current deployment. Inspect both web and worker identity when the worker exists.

Deploy a candidate that requires an additive migration. Inject a migration failure and verify that dependent web and worker versions do not start.

Dependencies

Development should track validated `main` commits automatically. A passing pull request for another commit must not authorize deployment of the squashed result. ## Scope Publish the built image to the Forgejo container registry and deploy it through Dokploy. Use the existing runner flow and inspect the installed Dokploy API and routing behavior. ## Acceptance criteria - The actual `main` commit passes all applicable required validation before deployment. The artifact record associates that commit, its image digest, and check results. - Dokploy pulls the selected image digest. It does not rebuild source. Web and available worker services use the same image and application version. - Apply the candidate's committed migrations before starting web or worker versions that need them. Serialize migration execution within the deployment. - Migration failure blocks rollout and leaves the existing compatible application running. Preserve migration failure evidence without automatically restoring the database. - Development uses separate databases, credentials, integrations, data, and notification destinations. It cannot read production participant data or send production notifications. - Failed validation leaves the current development deployment running. A raw push webhook cannot bypass the required checks. - Deployments serialize within the development environment. Superseded queued commits are skipped before deployment starts. An older deployment cannot overwrite a newer successful one. - CI correlates the asynchronous Dokploy request with its deployment result. An accepted API request alone cannot pass the job. - Completion requires readiness through the normal application entry point and the expected version and commit or image identity. - Cancellation, timeout, deployment error, failed readiness, and a healthy wrong build fail the deployment result. Failure evidence remains available. - Deployment credentials exist only in the trusted deployment job. Validation jobs cannot access production credentials, resources, or deployment privileges. ## Validation Use a disposable development target to exercise passing deployment, validation rejection, asynchronous failure, wrong identity, and superseded queue entries. Verify a failed check does not replace the current deployment. Inspect both web and worker identity when the worker exists. Deploy a candidate that requires an additive migration. Inject a migration failure and verify that dependent web and worker versions do not start. ## Dependencies - [#13: Enforce complete validation in the shared Forgejo runner flow](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/13). Deployment must consume the required CI result. - [#32: Use one application version across builds and release artifacts](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/32). The selected artifact needs consistent version and commit identity. - [#15: Enforce Python behavior coverage and mutation checks](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/15). The backend suite must gate development deployment. - [#9: Enforce frontend correctness and report runtime performance](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/9). Frontend validation must gate development deployment. - [#17: Scan tracked files and complete Git history for secrets](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/17). Secret scans must gate development deployment. - [#30: Block vulnerable dependencies and unsafe container configuration](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/30). Dependency and image scans must gate development deployment. - [#31: Scan the disposable authenticated API with ZAP](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/31). Authenticated DAST must gate development deployment. - [#8: Apply PostgreSQL migrations with release compatibility checks](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/8). Deployment must execute candidate migrations before dependent services start. ## Related work - [#16: Run durable PostgreSQL jobs with atomic effects](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/16)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
viacheslavshuka/quorum#34
No description provided.