Commit Graph
12 Commits
Author SHA1 Message Date
SluijsensandClaude Sonnet 5 c43528b7b2 Cancels superseded PR CI runs on a new push, never during a live deploy
Continuous Integration / config (pull_request) Successful in 11s
Continuous Integration / changes (pull_request) Successful in 22s
Continuous Integration / backend-build (pull_request) Successful in 5m33s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m50s
Continuous Integration / frontend-prepare (pull_request) Successful in 2m0s
Continuous Integration / backend-test (pull_request) Successful in 7m54s
Continuous Integration / frontend-build (pull_request) Successful in 2m9s
Continuous Integration / frontend-test (pull_request) Successful in 5m4s
Continuous Integration / frontend-lint (pull_request) Successful in 1m56s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 7m14s
Continuous Integration / deploy-test (pull_request) Skipped
A new push to a PR previously left the prior CI attempt running
independently instead of superseding it. Scoped strictly to
pull_request events, since deploy-test/deploy-production only ever
run on a push to master or a manual workflow_dispatch.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
2026-08-02 16:37:58 +02:00
SluijsensandClaude Sonnet 5 cfb06b28b6 Adds the Offerings module and retargets the CI/CD pipeline to Api.SlpSoftware
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
2026-08-02 16:23:09 +02:00
SluijsensandClaude Sonnet 5 b6e9c07c06 Replaces the backend-test MariaDB service with an explicit docker run
Continuous Integration / config (pull_request) Successful in 12s
Continuous Integration / changes (pull_request) Successful in 22s
Continuous Integration / backend-build (pull_request) Successful in 5m41s
Continuous Integration / vulnerability-scan (pull_request) Successful in 5m8s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m52s
Continuous Integration / backend-test (pull_request) Successful in 7m35s
Continuous Integration / frontend-build (pull_request) Successful in 2m18s
Continuous Integration / frontend-test (pull_request) Successful in 4m43s
Continuous Integration / frontend-lint (pull_request) Successful in 2m15s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 7m7s
Continuous Integration / deploy-test (pull_request) Skipped
The services: block was silently broken on this runner: job and service
containers both use host networking here, so the ports: mapping was
ignored and the mariadb:11 service ended up sharing the host's own port
3306 -- which something else on this runner already answers on (root auth
was rejected with a password nothing but this job ever set). Replaced with
an explicit `docker run` on host port 3307, bypassing that collision, plus
a readiness loop. Also fixes the readiness command itself: mariadb:11 does
not provide a `mysqladmin` alias, the correct binary is `mariadb-admin`
(verified locally against the exact image before pushing this).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
2026-08-02 11:24:41 +02:00
SluijsensandClaude Sonnet 5 0feedf9c01 Adds a MariaDB service to backend-test for SlpModularCms.Api.Tests
Continuous Integration / config (pull_request) Successful in 12s
Continuous Integration / changes (pull_request) Successful in 22s
Continuous Integration / backend-build (pull_request) Successful in 5m52s
Continuous Integration / vulnerability-scan (pull_request) Successful in 5m6s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m24s
Continuous Integration / backend-test (pull_request) Failing after 8m24s
Continuous Integration / frontend-build (pull_request) Successful in 2m14s
Continuous Integration / frontend-test (pull_request) Successful in 4m28s
Continuous Integration / frontend-lint (pull_request) Successful in 2m5s
Continuous Integration / publish-test (pull_request) Skipped
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-test (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
The new pipeline regression tests boot the real Api host via
WebApplicationFactory, which unconditionally runs the startup database
migration -- unlike every other test project here, which mocks or uses EF
Core InMemory. CI had no MariaDB service at all, so those tests failed on
the connection itself. Adds a mariadb service container to the backend-test
job plus a ConnectionStrings__DefaultConnection override for that step,
which overrides the appsettings.Development.json placeholder via standard
config layering without touching any committed appsettings file or
affecting local test runs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
2026-08-02 10:46:25 +02:00
SluijsensandClaude Sonnet 5 de06578444 Logs workflow_dispatch input values and skips publish-test on a manual run without deploy_test checked
Continuous Integration / config (pull_request) Successful in 12s
Continuous Integration / changes (pull_request) Successful in 30s
Continuous Integration / backend-build (pull_request) Successful in 4m52s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m45s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m28s
Continuous Integration / backend-test (pull_request) Successful in 5m52s
Continuous Integration / frontend-build (pull_request) Successful in 2m16s
Continuous Integration / frontend-test (pull_request) Successful in 4m23s
Continuous Integration / frontend-lint (pull_request) Successful in 1m58s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 6m31s
Continuous Integration / deploy-test (pull_request) Skipped
Gitea's UI has no reliable way to see a past run's dispatch input values, so the config job now echoes them into the log. publish-test previously always built and uploaded the test artifact regardless of the deploy_test/deploy_production selection, wasting a build on manual runs that were never going to deploy to test; it now mirrors publish-production by skipping when workflow_dispatch didn't check deploy_test. Push and pull_request runs are unaffected.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VhySVFARKAP89WqQ3Kff8M
2026-07-31 20:17:55 +02:00
SluijsensandClaude Sonnet 5 12b1df6ede Replaces unsupported failure()/cancelled() with explicit needs.<job>.result checks in publish gates
Continuous Integration / config (pull_request) Successful in 10s
Continuous Integration / changes (pull_request) Successful in 20s
Continuous Integration / backend-build (pull_request) Successful in 5m23s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m28s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m47s
Continuous Integration / backend-test (pull_request) Successful in 5m56s
Continuous Integration / frontend-build (pull_request) Successful in 2m11s
Continuous Integration / frontend-test (pull_request) Successful in 4m43s
Continuous Integration / frontend-lint (pull_request) Successful in 1m54s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 6m49s
Continuous Integration / deploy-test (pull_request) Skipped
Gitea Actions only implements always() from GitHub Actions' status-check functions; success(), failure(), and cancelled() aren't supported. publish-test/publish-production relied on !failure() && !cancelled() to let a run through when an unaffected gate job was skipped by the path filter while still blocking on an actual failure — rewritten to check needs.<job>.result explicitly instead, which Gitea does support.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VhySVFARKAP89WqQ3Kff8M
2026-07-31 16:53:46 +02:00
SluijsensandClaude Sonnet 5 dfc27fd5a2 Shortens deploy_production label, adds a deploy_test toggle for manual runs, and skips backend/frontend gates when that side of the repo has no changes
Continuous Integration / config (pull_request) Successful in 10s
Continuous Integration / changes (pull_request) Successful in 21s
Continuous Integration / backend-build (pull_request) Successful in 5m17s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m30s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m32s
Continuous Integration / backend-test (pull_request) Successful in 5m31s
Continuous Integration / frontend-build (pull_request) Successful in 2m10s
Continuous Integration / frontend-test (pull_request) Successful in 4m26s
Continuous Integration / frontend-lint (pull_request) Successful in 2m12s
Continuous Integration / publish-test (pull_request) Canceled after 0s
Continuous Integration / publish-production (pull_request) Canceled after 0s
Continuous Integration / deploy-test (pull_request) Canceled after 0s
Continuous Integration / deploy-production (pull_request) Canceled after 0s
Push-to-master keeps auto-deploying to test unchanged. A new deploy_test input (default false) lets a manual workflow_dispatch run opt into a test deploy instead of it firing by default. A new changes job (dorny/paths-filter) gates the backend and frontend build/test/lint jobs on whether their side of the repo actually changed, shortening runs that only touch one side; publish jobs still run whenever either side changed, and manual runs always run everything since there's no commit to diff against.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VhySVFARKAP89WqQ3Kff8M
2026-07-31 15:25:28 +02:00
Sluijsens 084b941204 Pins actions/setup-node to v3, skips DB backup when no database exists yet
Continuous Integration / config (pull_request) Successful in 10s
Continuous Integration / backend-build (pull_request) Successful in 4m57s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m47s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m51s
Continuous Integration / backend-test (pull_request) Successful in 5m17s
Continuous Integration / frontend-build (pull_request) Successful in 2m15s
Continuous Integration / frontend-test (pull_request) Successful in 4m24s
Continuous Integration / frontend-lint (pull_request) Successful in 2m10s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 6m19s
Continuous Integration / deploy-test (pull_request) Skipped
actions/setup-node@v4's Post step attempts a cache-save that fails hard on
this self-hosted Gitea Actions runner (no GHES cache API support), marking
frontend-prepare as failed and blocking its dependents even though the
actual install/build work succeeds. v3's older cache implementation doesn't
hit this. Also cleans up two stale comments left over from the /admin
MSBuild-target removal.

Also updates the documented backup script to skip cleanly (exit 0) when the
target database doesn't exist yet (MariaDB error 1049) rather than failing
the whole deploy - expected on a brand-new environment's first production
run, before migrations have ever had a chance to create it. Still fails hard
on any other error, so a real backup failure against an existing database
still blocks the deploy as intended.
2026-07-30 18:54:09 +02:00
Sluijsens f10d7b983e Reverts deploy-test to push/workflow_dispatch only, drops the pull_request trigger
Continuous Integration / config (pull_request) Successful in 9s
Continuous Integration / backend-build (pull_request) Successful in 5m22s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m44s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m39s
Continuous Integration / backend-test (pull_request) Successful in 5m11s
Continuous Integration / frontend-build (pull_request) Successful in 2m10s
Continuous Integration / frontend-test (pull_request) Successful in 4m27s
Continuous Integration / frontend-lint (pull_request) Successful in 1m56s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 6m24s
Continuous Integration / deploy-test (pull_request) Skipped
The pull_request trigger was a temporary convenience to test the deploy
pipeline itself against the real test environment on every PR push. Now
that the pipeline is verified working end to end, going back to only
deploying on a master push or manual dispatch avoids concurrent PRs
silently overwriting the single shared test environment.
2026-07-30 13:38:31 +02:00
Sluijsens 7c1d2aa520 Fixes /admin 404 by building the admin SPA before dotnet publish, not via an MSBuild target
Continuous Integration / config (pull_request) Successful in 10s
Continuous Integration / backend-build (pull_request) Successful in 4m52s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m50s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m44s
Continuous Integration / backend-test (pull_request) Successful in 5m37s
Continuous Integration / frontend-build (pull_request) Successful in 2m11s
Continuous Integration / frontend-test (pull_request) Successful in 4m33s
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 6m14s
Deploy (SCP) / deploy (pull_request) Successful in 1m20s
Continuous Integration / deploy-test (pull_request) Successful in 1m21s
The BuildAndCopyAdminFrontend MSBuild target (BeforeTargets=Publish) never actually
worked: files it created after project evaluation were silently absent from the
publish output, and forcing them in via an explicit Content item collided with the
SDK's own static-web-asset resolution. Verified locally with a clean obj/bin and a
fresh node_modules - every deploy so far genuinely shipped without wwwroot/admin.
Moves the frontend build + copy into its own CI step ahead of dotnet publish, so the
SDK's ordinary wwwroot handling picks it up with no custom MSBuild involved.

Also fixes unreadable <code> badges on the website placeholder page (no explicit
text color, relying on inherited body color pairing unreliably with the badge
background).
2026-07-30 11:10:17 +02:00
SluijsensandClaude Sonnet 5 92547efd47 Allows deploy-test to run on pull_request events too
Continuous Integration / config (pull_request) Canceled after 0s
Continuous Integration / backend-build (pull_request) Canceled after 0s
Continuous Integration / backend-test (pull_request) Canceled after 0s
Continuous Integration / vulnerability-scan (pull_request) Canceled after 0s
Continuous Integration / frontend-prepare (pull_request) Canceled after 0s
Continuous Integration / frontend-build (pull_request) Canceled after 0s
Continuous Integration / frontend-test (pull_request) Canceled after 0s
Continuous Integration / frontend-lint (pull_request) Canceled after 0s
Continuous Integration / publish-test (pull_request) Canceled after 0s
Continuous Integration / publish-production (pull_request) Canceled after 0s
Continuous Integration / deploy-test (pull_request) Canceled after 0s
Continuous Integration / deploy-production (pull_request) Canceled after 0s
So PR pushes deploy straight to the test environment, without a manual
workflow_dispatch each time. Only one test environment exists, so this
means concurrent PRs would overwrite each other's deploy - acceptable
with a single active PR, worth revisiting once that's no longer true.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig
2026-07-29 19:41:17 +02:00
Sluijsens 9f4ae475e7 U5 — the gate everything else has to pass
continuous_integration.yaml: six blocking checks, then a separate
publish per environment so a Vite build never gets tagged for the
wrong one, then a call into last commit's deploy workflow. Along the
way: the lint list had drifted (two problems not in the requirement,
one already fixed), and the Umami-origin gate needed a variable pair
of its own since the backend's side of that comparison lives on the
host, not in CI. Pinned the two vulnerable packages while at it.
2026-07-28 16:07:03 +02:00