deploy without node
Some checks failed
ci / site (push) Has been cancelled
publish-image / publish (push) Has been cancelled

This commit is contained in:
2026-02-10 02:52:14 -05:00
parent 03df2b3a6c
commit 3b0b97f139
25 changed files with 312 additions and 51 deletions

View File

@@ -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

View File

@@ -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

View File

@@ -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)

View File

@@ -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)