fix: generate new deployment tag when only env values change

[BrendanGalloway]

No description provided.

[gitvelocity-reviewer]

📊 Code Quality Score: 7/100

27 × 0.25 (Micro ESF) = 6.75, rounded to 7

Category	Score	Factors
🔭 Scope	4/20	Single file changed: .github/workflows/deploy-static.yaml. The change adds one new job output (env_changed), one new env var (ENV_CHANGED), and extends the tag-generation and push steps within the existing release-chart job. No new jobs, services, or external integrations are introduced.
🏗️ Architecture	3/20	The git push origin --follow-tags call is split into two explicit git push calls for branch and tag separately. A new env_changed output is threaded from the detect job to the release-chart job. No new module boundary or service dependency is introduced.
⚙️ Implementation	7/20	The file-classification elif condition is corrected from != envs/* to == envs/* with a new else branch for app_changed. A while-loop counter starting at n=2 checks git rev-parse for tag existence to find the next available ${BASE_TAG}.env.${n} suffix. A git diff --cached --quiet check gates the git commit call to avoid failing on an empty staging area in the env-only case.
⚠️ Risk	8/20	A bug in this workflow blocks all deployments to the affected environments. The tag-counter loop has a race condition: two concurrent env-only workflow runs can compute the same n and one git tag will fail. The split push means a tag-push failure after a successful branch push leaves the deployment state inconsistent, since Flux pins to the tag. No rollback plan is documented.
✅ Quality	4/15	No automated tests accompany the change, which is standard for CI YAML. Inline comments in the shell script explain the Flux tag format assumption, the empty-commit case, and the split-push rationale. The ENV_CHANGED variable is declared and printed in a log line but is not used in any conditional branch.
🔒 Perf / Security	1/5	No performance or security work is present. The git rev-parse loop adds a small number of git remote calls proportional to the number of existing env-suffixed tags, which is bounded in practice.

Was this score accurate? 👍 Yes · 👎 No

How this was scored →

_{Scored by GitVelocity · How are scores calculated?}