Deploy a preview per PR and remove it on close #306

New issue

Closed

opened 2026-10-09 09:19:51 +00:00 by root · 12 comments

root commented

2026-10-09 09:19:51 +00:00

(Migrated from gitlab.core-project.space)

Imported from GitHub amaurycoudr/chess-project#306, opened by @amaurycoudr on 2026-10-09 09:19 UTC.
Closed on GitHub on 2026-10-09 12:20 UTC as completed.

Parent

#303

What to build

Every PR whose head branch is in the repo gets a public preview at https://pr-<n>.chess.core-project.space, redeployed on each push and removed when the PR closes.

The preview workflow builds and pushes the image tagged for the PR, then deploys the same deploy compose as production as stack chess-pr-<n>, with its own host, ORIGIN_ALLOWLIST set to that origin, a deploy-time label, and a response-header middleware adding X-Robots-Tag: noindex. It posts the preview URL in one PR comment, updated rather than duplicated on later pushes. Fork PRs never reach a step that holds a secret.

On PR close (merged or not), a workflow removes the PR's stack with its volumes, and succeeds when the stack is already gone.

Seam: Workflow post-conditions

Acceptance criteria

Opening a PR from the repo deploys chess-pr-<n>, reachable over HTTPS with a valid certificate
A push to the PR redeploys the preview with the new commit's image
The PR carries exactly one comment with the preview URL
A fork PR deploys nothing and exposes no secret
The deploy workflow ends by checking the stack runs one container, HTTPS answers GET /, and the response carries X-Robots-Tag: noindex
Closing or merging the PR removes the stack and its volumes; the close workflow checks the stack is gone, and passes when it was already gone
Production is untouched by any preview deploy or cleanup

> _Imported from GitHub [amaurycoudr/chess-project#306](https://github.com/amaurycoudr/chess-project/issues/306), opened by [@amaurycoudr](https://github.com/amaurycoudr) on 2026-10-09 09:19 UTC._ > _Closed on GitHub on 2026-10-09 12:20 UTC as completed._  --- ## Parent #303 ## What to build Every PR whose head branch is in the repo gets a public preview at `https://pr-<n>.chess.core-project.space`, redeployed on each push and removed when the PR closes. The preview workflow builds and pushes the image tagged for the PR, then deploys the same deploy compose as production as stack `chess-pr-<n>`, with its own host, `ORIGIN_ALLOWLIST` set to that origin, a deploy-time label, and a response-header middleware adding `X-Robots-Tag: noindex`. It posts the preview URL in one PR comment, updated rather than duplicated on later pushes. Fork PRs never reach a step that holds a secret. On PR close (merged or not), a workflow removes the PR's stack with its volumes, and succeeds when the stack is already gone. Seam: Workflow post-conditions ## Acceptance criteria - [ ] Opening a PR from the repo deploys `chess-pr-<n>`, reachable over HTTPS with a valid certificate - [ ] A push to the PR redeploys the preview with the new commit's image - [ ] The PR carries exactly one comment with the preview URL - [ ] A fork PR deploys nothing and exposes no secret - [ ] The deploy workflow ends by checking the stack runs one container, HTTPS answers `GET /`, and the response carries `X-Robots-Tag: noindex` - [ ] Closing or merging the PR removes the stack and its volumes; the close workflow checks the stack is gone, and passes when it was already gone - [ ] Production is untouched by any preview deploy or cleanup

root commented

2026-10-09 09:19:51 +00:00

(Migrated from gitlab.core-project.space)

GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links).

Parent (sub-issue of): #303
Blocked by: #304
Blocking: #310, #308, #307

> _GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links)._  - Parent (sub-issue of): #303 - Blocked by: #304 - Blocking: #310, #308, #307

root (Migrated from gitlab.core-project.space) closed this issue

2026-10-09 12:20:43 +00:00

root commented

2026-10-13 08:39:26 +00:00

(Migrated from gitlab.core-project.space)

mentioned in issue #307