deploy without node
This commit is contained in:
@@ -7,11 +7,10 @@ The site MUST provide a blog index page at `/blog` that lists WordPress posts as
|
||||
- excerpt/summary
|
||||
- publish date
|
||||
|
||||
The card MUST render a meta row with:
|
||||
The card MUST render a footer bar that includes:
|
||||
- publish date on the left
|
||||
- views on the right when available (if views are not provided by the dataset, the card MUST omit views without breaking layout)
|
||||
|
||||
The card MUST render a footer row showing the content source label (e.g., `blog`).
|
||||
- a content source label (e.g., `blog`)
|
||||
|
||||
The listing MUST be ordered by publish date descending (newest first).
|
||||
|
||||
@@ -31,4 +30,4 @@ Each post card MUST be instrumented with Umami Track Events data attributes and
|
||||
|
||||
#### Scenario: Blog post card layout is standardized
|
||||
- **WHEN** `/blog` renders a blog post card
|
||||
- **THEN** the card shows featured image (when available), title, trimmed excerpt, meta row (date + optional views), and a footer source label
|
||||
- **THEN** the card shows featured image (when available), title, trimmed excerpt, and a footer bar containing date, optional views, and a source label
|
||||
@@ -7,10 +7,10 @@ The standard card layout MUST be:
|
||||
- featured image displayed prominently at the top (when available)
|
||||
- title
|
||||
- summary/excerpt text, trimmed to a fixed maximum length
|
||||
- meta row showing:
|
||||
- footer bar showing:
|
||||
- publish date on the left
|
||||
- views on the right (when available)
|
||||
- footer row showing the content source (e.g., `youtube`, `podcast`, `blog`)
|
||||
- views when available (if omitted, the footer MUST still render cleanly)
|
||||
- the content source label (e.g., `youtube`, `podcast`, `blog`)
|
||||
|
||||
If a field is not available (for example, views for some sources), the card MUST still render cleanly with that field omitted.
|
||||
|
||||
@@ -20,9 +20,8 @@ If a field is not available (for example, views for some sources), the card MUST
|
||||
|
||||
#### Scenario: Card renders without views
|
||||
- **WHEN** a content item has no views data
|
||||
- **THEN** the card renders the meta row with date and omits views without breaking the layout
|
||||
- **THEN** the card renders the footer bar with date + source and omits views without breaking the layout
|
||||
|
||||
#### Scenario: Card renders without featured image
|
||||
- **WHEN** a content item has no featured image
|
||||
- **THEN** the card renders a placeholder media area and still renders the remaining fields
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
## 1. Discovery And Current State
|
||||
|
||||
- [x] 1.1 Identify current deploy target and mechanism (compose/swarm/k8s, image vs files) and document constraints in `README` or `ops/` docs
|
||||
- [x] 1.2 Identify the content source(s) that define "latest content" (e.g., WordPress/API) and how builds currently fetch content
|
||||
- [x] 1.3 Confirm current build output (static assets) and runtime server (e.g., nginx) requirements
|
||||
|
||||
## 2. Build And Publish A Deployable Artifact
|
||||
|
||||
- [x] 2.1 Ensure the repo can produce a deterministic production build inside CI (no host dependencies)
|
||||
- [x] 2.2 Create or update a Dockerfile to build the site and package the built output into a runtime image
|
||||
- [x] 2.3 Add build metadata to the image (tagging convention and/or embedded version file)
|
||||
- [x] 2.4 Configure CI to build and publish the image to a registry accessible by the server
|
||||
|
||||
## 3. Server-Side Docker-Only Refresh Workflow
|
||||
|
||||
- [x] 3.1 Add or update the server Docker Compose/service definition to run the published image
|
||||
- [x] 3.2 Add documented operator commands to refresh to the latest image (pull + restart)
|
||||
- [x] 3.3 Add a verification command/procedure to show the currently deployed version (tag/digest/build metadata)
|
||||
- [x] 3.4 Define rollback procedure to re-deploy a previous known-good tag/digest
|
||||
|
||||
## 4. Validation
|
||||
|
||||
- [x] 4.1 Validate a refresh on a test/staging server: pull latest image, restart, confirm content changes are visible
|
||||
- [x] 4.2 Validate failure mode: simulate pull failure and confirm the existing site remains serving
|
||||
- [x] 4.3 Update docs with a minimal "runbook" for operators (refresh, verify, rollback)
|
||||
@@ -1,25 +0,0 @@
|
||||
## 1. Discovery And Current State
|
||||
|
||||
- [ ] 1.1 Identify current deploy target and mechanism (compose/swarm/k8s, image vs files) and document constraints in `README` or `ops/` docs
|
||||
- [ ] 1.2 Identify the content source(s) that define "latest content" (e.g., WordPress/API) and how builds currently fetch content
|
||||
- [ ] 1.3 Confirm current build output (static assets) and runtime server (e.g., nginx) requirements
|
||||
|
||||
## 2. Build And Publish A Deployable Artifact
|
||||
|
||||
- [ ] 2.1 Ensure the repo can produce a deterministic production build inside CI (no host dependencies)
|
||||
- [ ] 2.2 Create or update a Dockerfile to build the site and package the built output into a runtime image
|
||||
- [ ] 2.3 Add build metadata to the image (tagging convention and/or embedded version file)
|
||||
- [ ] 2.4 Configure CI to build and publish the image to a registry accessible by the server
|
||||
|
||||
## 3. Server-Side Docker-Only Refresh Workflow
|
||||
|
||||
- [ ] 3.1 Add or update the server Docker Compose/service definition to run the published image
|
||||
- [ ] 3.2 Add documented operator commands to refresh to the latest image (pull + restart)
|
||||
- [ ] 3.3 Add a verification command/procedure to show the currently deployed version (tag/digest/build metadata)
|
||||
- [ ] 3.4 Define rollback procedure to re-deploy a previous known-good tag/digest
|
||||
|
||||
## 4. Validation
|
||||
|
||||
- [ ] 4.1 Validate a refresh on a test/staging server: pull latest image, restart, confirm content changes are visible
|
||||
- [ ] 4.2 Validate failure mode: simulate pull failure and confirm the existing site remains serving
|
||||
- [ ] 4.3 Update docs with a minimal "runbook" for operators (refresh, verify, rollback)
|
||||
Reference in New Issue
Block a user