User asked why every release tonight had the same "sequence number"
(quant_20260711.1.*) despite creating three of them. Confirmed via
API: tags b7591fb, 6ab270f, and e49922e all exist for 2026-07-11, all
claiming to be deploy #1.
Root cause: `actions/checkout@v4` (no fetch-depth/fetch-tags options)
does a shallow, tags-less clone by default. Each prepare-release.yml
run happens in a brand-new container, so `git tag -l "quant_${TODAY}.*"`
always sees zero local tags regardless of how many releases actually
exist -- DEPLOY_COUNT was permanently stuck at 0+1=1.
Fix: query GET /repos/{repo}/tags via the Gitea API (same token/curl
pattern already used elsewhere in this workflow) to count today's
actual tags, instead of relying on the job's local, incomplete git
state.
Production incident: quant.taxbaik.com/login threw 28P01 (password
authentication failed) after the July 7 deployment's
appsettings.Production.json carried a stale DB password. Root cause
chain:
1. The DB password for quantengine_app had been rotated at some
point; the new password was saved to
/home/kjh2064/.config/quantengine.env on the server, but that
file was never wired into the quantengine.service systemd unit
(no EnvironmentFile= directive), so it was silently unused.
2. Every appsettings.Production.json we've generated in CI
(including tonight's prepare-release.yml) baked in a PLACEHOLDER
password ("quantengine_app") that was never the real credential
to begin with -- copied forward from an earlier debugging session
without ever being verified against the live DB.
Immediate production fix (out of band, via SSH): patched the active
deployment's appsettings.Production.json with the current working
password (verified via direct psql connection) and restarted the
service. Login confirmed HTTP 200 with a clean journalctl afterward.
This commit fixes the root cause in the pipeline: prepare-release.yml
no longer writes a ConnectionStrings block into the artifact at all.
Baking any DB password (even a correct one) into a build artifact
that ships as a downloadable Gitea Release asset is unsafe and goes
stale on every credential rotation. The correct fix is for
quantengine.service to load ConnectionStrings__DefaultConnection from
/home/kjh2064/.config/quantengine.env via systemd's EnvironmentFile=,
which overrides appsettings.Production.json at runtime per standard
ASP.NET Core configuration precedence. That unit-file edit requires
interactive sudo and must be applied by hand on the server (tracked
separately, not part of this commit).
IMPORTANT: the release quant_20260711.1.6ab270f already published
tonight was built before this fix and still lacks any DB config --
do not deploy it via deploy-prod.yml until the systemd
EnvironmentFile wiring is confirmed on the server, or the login
outage will recur.
Root cause found via SSH log analysis (actions_log/.../2326.log):
'gh release create' failed with exit code 127 (command not found).
The act_runner Docker image used for jobs does not ship the
GitHub CLI (gh), so any step relying on it fails immediately.
Fix: Replace gh CLI calls with direct Gitea REST API calls using
curl, which is available in the base image:
1. POST /repos/{repo}/releases -- create release, parse id via python3
2. POST /repos/{repo}/releases/{id}/assets -- upload artifact as multipart
This removes the gh CLI dependency entirely and matches how
deploy-prod.yml already talks to Gitea (curl + REST API).
Root cause found via SSH log analysis (actions_log/.../2324.log):
'git config user.name' returned exit code 1 (no global identity set
in the Gitea Actions runner container), and since the step uses
'bash -e -o pipefail', the script aborted immediately at that line
before ever reaching 'git tag'.
Fix: explicitly set git user.name/user.email before tagging, and
remove the fragile bare 'git config user.name' debug calls.
Also removed the '|| echo ...continuing' fallback on git push so
push failures are now visible as real failures instead of swallowed.
- Add git config output for debugging tag creation
- Add artifact existence check
- Add gh CLI version check
- Add explicit --repo parameter for gh release create
- Make tag push non-fatal to continue workflow
- Auto-generate version format: quant_YYYYMMDD.count.hash
- Count existing tags for today to determine deploy count
- Add job outputs for version and commit
- Simplify release notes format to fix YAML parsing error
- Make version input optional (auto-generated if empty)
kjh2064