Monitoring Setup: operations/plans/monitoring-setup-plan.md and
operations/monitoring/monitoring-instructions.md, covering Sentry alert
rules on the security_event tag, UptimeRobot's 6 liveness monitors, and
the two new Umami website entries for the admin SPA.
deployment-instructions.md gains a missing Observability__Environment
host var (without it, both environments would tag Sentry events as
"Production"), the nginx client_max_body_size fix for the 413 seen on
publish-test/production artifact uploads, and two troubleshooting notes
on Gitea Actions re-run behaviour: re-running deploy-test/production
alone loses the run's uploaded artifact, and re-running all jobs on an
existing (rather than a brand new) run can replay stale secrets.
deploy-scp.yaml: step names no longer show literal unresolved
${{ inputs.* }} text (Gitea doesn't interpolate that context in step
names), and a temporary debug step logs PI_MAIN_USERNAME/PASSWORD
length plus a username equality check to diagnose a persistent
Permission denied during the SSH steps, without ever logging the
secret values themselves.
Monitoring Setup: operations/plans/monitoring-setup-plan.md and
operations/monitoring/monitoring-instructions.md, covering Sentry alert
rules on the security_event tag, UptimeRobot's 6 liveness monitors, and
the two new Umami website entries for the admin SPA.
deployment-instructions.md gains a missing Observability__Environment
host var (without it, both environments would tag Sentry events as
"Production"), the nginx client_max_body_size fix for the 413 seen on
publish-test/production artifact uploads, and two troubleshooting notes
on Gitea Actions re-run behaviour: re-running deploy-test/production
alone loses the run's uploaded artifact, and re-running all jobs on an
existing (rather than a brand new) run can replay stale secrets.
deploy-scp.yaml: step names no longer show literal unresolved
${{ inputs.* }} text (Gitea doesn't interpolate that context in step
names), and a temporary debug step logs PI_MAIN_USERNAME/PASSWORD
length plus a username equality check to diagnose a persistent
Permission denied during the SSH steps, without ever logging the
secret values themselves.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig
Monitoring Setup: operations/plans/monitoring-setup-plan.md and
operations/monitoring/monitoring-instructions.md, covering Sentry alert
rules on the security_event tag, UptimeRobot's 6 liveness monitors, and
the two new Umami website entries for the admin SPA.
deployment-instructions.md gains a missing Observability__Environment
host var (without it, both environments would tag Sentry events as
"Production"), the nginx client_max_body_size fix for the 413 seen on
publish-test/production artifact uploads, and two troubleshooting notes
on Gitea Actions re-run behaviour: re-running deploy-test/production
alone loses the run's uploaded artifact, and re-running all jobs on an
existing (rather than a brand new) run can replay stale secrets.
deploy-scp.yaml: step names no longer show literal unresolved
${{ inputs.* }} text (Gitea doesn't interpolate that context in step
names), and a temporary debug step logs PI_MAIN_USERNAME/PASSWORD
length plus a username equality check to diagnose a persistent
Permission denied during the SSH steps, without ever logging the
secret values themselves.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig
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
Username is now confirmed correct (14 chars, exact match). This checks
whether the password secret carries leading/trailing whitespace or a
stray newline picked up when it was pasted into Gitea - the length
differs from the trimmed length if so, without ever logging the
password's actual characters.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig
Every ssh/scp step interpolated ${{ secrets.PI_MAIN_PASSWORD }} and
${{ secrets.PI_MAIN_USERNAME }} directly into the run: shell text.
Gitea/GitHub Actions substitutes that as literal text before bash ever
sees it, so any shell-metacharacter in the password ($, `, ", \) gets
re-interpreted by bash instead of passed through - silently changing
what sshpass actually receives. This plausibly explains a persistent
"Permission denied" even after the username and password length were
both confirmed correct via the debug step (which used env: and so
never hit this).
All five steps now receive SSH_USER/SSH_PASS/SSH_PORT/SSH_HOST via
env:, which bash treats as opaque values with no re-parsing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig
The PI_MAIN_USERNAME/PASSWORD debug step served its purpose (found the
shell-metacharacter password bug fixed in 51488d6) and is removed now
that deploy-test gets past authentication.
"Link persistent website content" then failed with `ln: failed to
create symbolic link '.../wwwroot/web': No such file or directory` -
dotnet publish only emits a wwwroot/ folder when the source project's
own wwwroot has content, so a release built before any frontend/website
content exists can land with no wwwroot/ directory at all, not merely
an empty wwwroot/web/. `ln -s` can't create the missing parent
directory itself. Added `mkdir -p $RELEASE_DIR/wwwroot` before the
existing rm/ln pair to guarantee the parent exists either way.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig
ModuleOrchestrator already discovers SlpModularCms.Modules.*.dll from disk at
startup via reflection, so this needed no code change — only a persistent
location (mirroring shared/wwwroot-web) that survives release swaps, and a
deploy-scp.yaml step to symlink its contents into each new release before
restart.
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).
5000ms was occasionally too tight on the self-hosted Actions runner for
lazy-loaded routes gated behind an async setup-status check (observed on
SettingsPage.test.tsx, passed reliably locally). Bumps to 10000ms across all
nine test files using that pattern, and raises vite.config.ts's global
testTimeout from 15000 to 20000 to keep headroom above it.
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.
Sluijsens
marked the pull request as ready for review 2026-07-30 13:46:26 +02:00
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Monitoring Setup: operations/plans/monitoring-setup-plan.md and
operations/monitoring/monitoring-instructions.md, covering Sentry alert
rules on the security_event tag, UptimeRobot's 6 liveness monitors, and
the two new Umami website entries for the admin SPA.
deployment-instructions.md gains a missing Observability__Environment
host var (without it, both environments would tag Sentry events as
"Production"), the nginx client_max_body_size fix for the 413 seen on
publish-test/production artifact uploads, and two troubleshooting notes
on Gitea Actions re-run behaviour: re-running deploy-test/production
alone loses the run's uploaded artifact, and re-running all jobs on an
existing (rather than a brand new) run can replay stale secrets.
deploy-scp.yaml: step names no longer show literal unresolved
${{ inputs.* }} text (Gitea doesn't interpolate that context in step
names), and a temporary debug step logs PI_MAIN_USERNAME/PASSWORD
length plus a username equality check to diagnose a persistent
Permission denied during the SSH steps, without ever logging the
secret values themselves.
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig
Monitoring Setup: operations/plans/monitoring-setup-plan.md and operations/monitoring/monitoring-instructions.md, covering Sentry alert rules on the security_event tag, UptimeRobot's 6 liveness monitors, and the two new Umami website entries for the admin SPA. deployment-instructions.md gains a missing Observability__Environment host var (without it, both environments would tag Sentry events as "Production"), the nginx client_max_body_size fix for the 413 seen on publish-test/production artifact uploads, and two troubleshooting notes on Gitea Actions re-run behaviour: re-running deploy-test/production alone loses the run's uploaded artifact, and re-running all jobs on an existing (rather than a brand new) run can replay stale secrets. deploy-scp.yaml: step names no longer show literal unresolved ${{ inputs.* }} text (Gitea doesn't interpolate that context in step names), and a temporary debug step logs PI_MAIN_USERNAME/PASSWORD length plus a username equality check to diagnose a persistent Permission denied during the SSH steps, without ever logging the secret values themselves. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBigEvery ssh/scp step interpolated ${{ secrets.PI_MAIN_PASSWORD }} and ${{ secrets.PI_MAIN_USERNAME }} directly into the run: shell text. Gitea/GitHub Actions substitutes that as literal text before bash ever sees it, so any shell-metacharacter in the password ($, `, ", \) gets re-interpreted by bash instead of passed through - silently changing what sshpass actually receives. This plausibly explains a persistent "Permission denied" even after the username and password length were both confirmed correct via the debug step (which used env: and so never hit this). All five steps now receive SSH_USER/SSH_PASS/SSH_PORT/SSH_HOST via env:, which bash treats as opaque values with no re-parsing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015FffvxxJp5wG34Ru48GBig