SluijsensandClaude Sonnet 5
cfb06b28b6
Continuous Integration / config (pull_request) Successful in 12s
Continuous Integration / changes (pull_request) Successful in 22s
Continuous Integration / backend-build (pull_request) Successful in 5m53s
Continuous Integration / vulnerability-scan (pull_request) Successful in 5m46s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m54s
Continuous Integration / backend-test (pull_request) Successful in 7m37s
Continuous Integration / frontend-build (pull_request) Successful in 2m14s
Continuous Integration / frontend-test (pull_request) Successful in 4m59s
Continuous Integration / frontend-lint (pull_request) Successful in 2m2s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 7m34s
Continuous Integration / deploy-test (pull_request) Skipped
Implements Unit 2 "Offerings" (backend module, admin CRUD UI with drag-and-drop reordering, public GET /api/v1/offerings endpoint) and executes the feature's D-15 CI/CD cutover, switching the deploy pipeline's build/publish target from SlpModularCms.Api to SlpModularCms.Api.SlpSoftware. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
60 lines
4.5 KiB
Markdown
60 lines
4.5 KiB
Markdown
# Deployment Setup Plan — slpsoftware-api (D-15 Cutover)
|
|
|
|
## Investigation (Before Drafting Anything)
|
|
|
|
Read `.gitea/workflows/continuous_integration.yaml`, `.gitea/workflows/deploy-scp.yaml`, and
|
|
`gitea-deployment-workflow/operations/deployment/{deployment-instructions.md,rollback-plan.md}` in
|
|
full before touching anything, per D-7's "extend, don't duplicate" instruction.
|
|
|
|
- **`deploy-scp.yaml` needs zero changes.** It never hardcodes an entry-point `.dll` name anywhere —
|
|
it uploads whatever the publish artifact contains and restarts a `service_name` input (a plain
|
|
string). The cutover is invisible to this file.
|
|
- **`continuous_integration.yaml` hardcodes `SlpModularCms.Api` in exactly 6 lines**, all inside
|
|
`publish-test`/`publish-production` (3 each): the "Build admin frontend" step's
|
|
`mkdir -p ../src/SlpModularCms.Api/wwwroot/admin` + `cp -r dist/. ../src/SlpModularCms.Api/wwwroot/admin/`,
|
|
and the "Publish" step's `working-directory: src/SlpModularCms.Api`. Every other `SlpModularCms.Api`
|
|
reference in the file is `SlpModularCms.Api.Tests` (the `backend-test` job) — Unit 1's own pipeline
|
|
regression suite, deliberately scoped to `Api` only (NFR-CS-01), and correctly untouched here: `Api`
|
|
keeps existing as the local dev host (D-8), so its own regression tests still make sense to run.
|
|
- **`deployment-instructions.md` § 1.6**'s systemd unit `ExecStart` lines reference
|
|
`SlpModularCms.Api.dll` explicitly — this is **host configuration**, per the doc's own framing
|
|
("everything here is host configuration the workflow assumes already exists — `deploy-scp.yaml`
|
|
never creates any of it"). Updating the *documented* command is this feature's job; applying it to
|
|
the *actual, already-running* systemd units on the Pi is the user's own manual step, same as every
|
|
other host-side item in that document — this session has no access to the Pi.
|
|
- **No nginx changes** (D-6, already decided) — the proxy Pi's server blocks point at pi-main's port,
|
|
not at a specific executable; whichever `.dll` is running behind that port is invisible to nginx.
|
|
- **No database change** — same customer/instance, same domain, same `DB_NAME` (`SlpSoftware<Env>`);
|
|
the cutover only changes which project's compiled output the existing systemd units execute.
|
|
- **No Gitea Actions variables/secrets change** — `DEPLOY_PATH_*`, `SERVICE_NAME_*`,
|
|
`HEALTH_CHECK_URL_*`, and every other `vars.*`/`secrets.*` already describe the *target* (paths,
|
|
service names, domains), none of which change in a same-host, same-service-name cutover.
|
|
- **`rollback-plan.md` needs zero changes** — it operates entirely at the release-directory/symlink
|
|
level (`current` → `releases/<timestamp>`), never referencing a specific `.dll` name.
|
|
|
|
## Why No Questions This Time
|
|
|
|
Every decision this stage would normally ask about is already made and traced in `requirements.md`:
|
|
D-6 (no nginx change), D-7 (extend the existing pipeline, don't fork it), D-8 (`Api` stays as local
|
|
dev host, unaffected), D-15 (this is a cutover, not side-by-side). This stage is mechanical execution
|
|
of already-approved decisions, not new design — flagging that explicitly rather than manufacturing a
|
|
question with no real alternative to weigh.
|
|
|
|
## Checklist
|
|
|
|
- [x] Update `continuous_integration.yaml`: `SlpModularCms.Api` → `SlpModularCms.Api.SlpSoftware` in
|
|
the 6 identified lines (3 in `publish-test`, 3 in `publish-production`) — nowhere else
|
|
- [x] Update `gitea-deployment-workflow/operations/deployment/deployment-instructions.md` § 1.6:
|
|
systemd unit `ExecStart` lines → `SlpModularCms.Api.SlpSoftware.dll`, with an explicit note
|
|
that this is a **cutover the user must apply by hand** to the Pi's already-existing
|
|
`slpsoftware-test.service`/`slpsoftware-production.service` unit files (this session cannot
|
|
reach the Pi) — directly answering the user's earlier question about whether those two unit
|
|
files need editing
|
|
- [x] Create `aidlc-docs/features/slpsoftware-api/operations/deployment/deployment-instructions.md`
|
|
as a short feature-local pointer document: this feature does not own a separate deployment
|
|
pipeline, it extends `gitea-deployment-workflow`'s — record that relationship plus exactly what
|
|
changed and why, rather than duplicating the full instructions
|
|
- [x] Verify no other file in the repo hardcodes `SlpModularCms.Api` in a way that's actually about
|
|
*this pipeline's deploy target* (as opposed to `Api`'s own continued existence as local dev
|
|
host, or `Api.Tests`, both of which are correctly unaffected)
|