docs(getting-started): deploy from registry images + upgrade guide#6
docs(getting-started): deploy from registry images + upgrade guide#6Lalatenduswain wants to merge 1 commit into
Conversation
Add a 'Deploy Without Cloning the Repository' section with a self-contained docker-compose.yml that uses only the published ghcr.io/ferriskey images, and an 'Upgrading FerrisKey' section covering pull, re-run migrations, and restart. Addresses ferriskey/ferriskey#1032
📝 WalkthroughWalkthroughDocumentation update adds two new sections to the getting-started guide: a Docker Compose deployment path using published FerrisKey images from ghcr.io, and an upgrade workflow guide covering image updates and database migrations using the db-migrations service. ChangesGetting Started Guide Enhancements
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
apps/docs/src/content/docs/discover/default/en/getting-started.mdx (2)
71-76: 💤 Low valueConsider adding the
-Uflag to the health check for explicitness.While
pg_isready -d ferriskeyworks, explicitly specifying the user with-U ferriskeymakes the health check more consistent with the definedPOSTGRES_USERenvironment variable and clearer about which connection parameters are being tested.✨ Optional enhancement
healthcheck: - test: ["CMD-SHELL", "pg_isready -d ferriskey"] + test: ["CMD-SHELL", "pg_isready -U ferriskey -d ferriskey"] interval: 10s🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/docs/src/content/docs/discover/default/en/getting-started.mdx` around lines 71 - 76, Update the Docker healthcheck command so it explicitly tests the configured DB user: modify the healthcheck test entry that currently runs pg_isready -d ferriskey to include the -U flag (pg_isready -d ferriskey -U ferriskey) so it checks connection parameters consistent with the POSTGRES_USER; locate the healthcheck block and update the test array entry accordingly.
132-154: ⚖️ Poor tradeoffConsider documenting expected downtime during upgrades.
The upgrade process will cause brief downtime when the API service restarts with the new image (step 3). For production deployments requiring zero-downtime upgrades, consider adding a note about using rolling updates, blue-green deployments, or Docker Swarm/Kubernetes strategies.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/docs/src/content/docs/discover/default/en/getting-started.mdx` around lines 132 - 154, Add a short note under the "Restart the application" step explaining that restarting the API will cause brief downtime and, for production requiring zero-downtime upgrades, recommend strategies such as rolling updates, blue‑green deployments, or orchestration solutions (Docker Swarm/Kubernetes) and link or reference relevant docs; update the "Restart the application" step content to include this advisory and a brief pointer to the alternative deployment strategies.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/docs/src/content/docs/discover/default/en/getting-started.mdx`:
- Around line 132-154: Insert a new step titled "Back up your database"
immediately before the existing "Pull the new images" step that tells users to
create and offline backup of the database and store it in a safe location
(mention using the running DB container via docker compose exec and pg_dump as
the method), and note that this backup can be used to restore if migrations
fail; keep the rest of the flow (the "Pull the new images", "Apply new
migrations" which runs db-migrations -> sqlx migrate run, and "Restart the
application" steps) unchanged.
---
Nitpick comments:
In `@apps/docs/src/content/docs/discover/default/en/getting-started.mdx`:
- Around line 71-76: Update the Docker healthcheck command so it explicitly
tests the configured DB user: modify the healthcheck test entry that currently
runs pg_isready -d ferriskey to include the -U flag (pg_isready -d ferriskey -U
ferriskey) so it checks connection parameters consistent with the POSTGRES_USER;
locate the healthcheck block and update the test array entry accordingly.
- Around line 132-154: Add a short note under the "Restart the application" step
explaining that restarting the API will cause brief downtime and, for production
requiring zero-downtime upgrades, recommend strategies such as rolling updates,
blue‑green deployments, or orchestration solutions (Docker Swarm/Kubernetes) and
link or reference relevant docs; update the "Restart the application" step
content to include this advisory and a brief pointer to the alternative
deployment strategies.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: b1c98215-10bc-4bce-a91e-5630922b669a
📒 Files selected for processing (1)
apps/docs/src/content/docs/discover/default/en/getting-started.mdx
| ::::step-group | ||
| :::step{title="Pull the new images"} | ||
| ```bash | ||
| docker compose pull | ||
| ``` | ||
| ::: | ||
|
|
||
| :::step{title="Apply new migrations"} | ||
| The `db-migrations` service runs `sqlx migrate run`, which only applies migrations that have not run yet — so it is safe to run on every upgrade: | ||
|
|
||
| ```bash | ||
| docker compose up -d db-migrations | ||
| ``` | ||
| ::: | ||
|
|
||
| :::step{title="Restart the application"} | ||
| Once migrations complete, recreate the API and web app on the new images: | ||
|
|
||
| ```bash | ||
| docker compose up -d api webapp | ||
| ``` | ||
| ::: | ||
| :::: |
There was a problem hiding this comment.
Add database backup recommendation before upgrade.
The upgrade workflow does not mention backing up the database before pulling new images and applying migrations. Database backups are a critical safety measure before any schema migration, as migrations can be irreversible and may encounter unexpected issues.
📋 Suggested addition of backup step
Consider adding a step before "Pull the new images":
:::step{title="Back up your database"}
Before upgrading, create a database backup:
\```bash
docker compose exec db pg_dump -U ferriskey ferriskey > backup-$(date +%Y%m%d-%H%M%S).sql
\```
Store this backup in a safe location. In case of migration issues, you can restore from this backup.
:::🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/docs/src/content/docs/discover/default/en/getting-started.mdx` around
lines 132 - 154, Insert a new step titled "Back up your database" immediately
before the existing "Pull the new images" step that tells users to create and
offline backup of the database and store it in a safe location (mention using
the running DB container via docker compose exec and pg_dump as the method), and
note that this backup can be used to restore if migrations fail; keep the rest
of the flow (the "Pull the new images", "Apply new migrations" which runs
db-migrations -> sqlx migrate run, and "Restart the application" steps)
unchanged.
2 participants
Summary
Addresses ferriskey/ferriskey#1032, which asks two questions the getting-started guide didn't answer:
Changes
Adds two sections to the English getting-started page:
docker-compose.ymlusing onlyghcr.io/ferriskey/*images (nobuild:context, no checkout). It mirrors the repo'sregistryprofile and relies on the migration files baked into theferriskey-apiimage, so no source tree is needed. Notes that it can be adapted to a Swarm stack, plus aninfocallout on pinning image tags for production.db-migrations→ restart flow, with awarningcallout on keepingapianddb-migrationson the same tag.Notes
docker-compose.yamlregistryprofile.step-group/step,calloutwithinfo/warningvariants).Summary by CodeRabbit