kjh2064/KArtSell.Aegis

Files

T

kjh2064 63a95c9242 fix(deploy): implement release version tagging for VITE_APP_VERSION

Deployment pipeline was computing version sequence (YYYY.MM.DD.N) by
counting existing vYYYY.MM.DD.* git tags, but the pipeline never created
those tags. Result: VERSION_SEQUENCE always resolved to 1, making the
"daily sequence" half of the contract decorative.

Now: After successful deployment to production, pipeline automatically
creates and pushes release tag vYYYY.MM.DD.N.SHA10 (e.g. v2026.08.07.1.abc1234567).
Uniqueness preserved even on same-day re-deploys. Permissions upgraded:
contents: read → write for tag push.

AGENTS.md: Right-Way (root cause fixed, not bandaged).

Ref: DEPLOY_FRONTEND_ARTIFACT_CONTRACT.md section "Bug Fix: Version Sequence Tagging"

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

2026-08-07 17:14:03 +09:00

1.4 KiB

Raw Blame History

배포 frontend artifact 계약

Source

운영 배포 Run 3357 로그: dotnet publish 전 frontend build 단계 없음
운영 bundle에 app-version 및 UI contract 4.0 marker 없음
frontend의 재현 가능한 pnpm-lock.yaml 및 기존 CI frontend job

Decision

배포 workflow는 Host publish 전에 다음 규칙으로 버전을 계산하고 frontend를 재생성한다.

YYYY.MM.DD.<당일 release 순번>.<commit SHA 10자리>

당일 순번은 vYYYY.MM.DD.* release tag 개수에 1을 더해 계산한다. 예: 2026.08.06.1.acaa731b3f. 생성된 frontend/dist를 Host wwwroot에 복사하고, app-version, UI contract 4.0, 계산된 전체 버전 marker가 없으면 배포를 중단한다.

Evidence / Unknown

Source 변경과 운영 artifact를 분리하지 않고, 매 배포 시 동일 commit에서 재생성한다.
실제 운영 반영 증거는 이 Slice의 CI 및 deploy run 완료 후 보존한다.

Bug Fix: Version Sequence Tagging

Issue: Version sequence 계산이 vYYYY.MM.DD.* git tag 존재를 전제로 카운트하지만, 그 tag를 생성/푸시하는 코드가 없었다. Fix: 배포 후 release tag v${VITE_APP_VERSION} (e.g. v2026.08.07.1.abc1234567)를 자동 생성/푸시. Workflow: .gitea/workflows/deploy.yml - 새 스텝 "Tag release version" 추가; permissions.contents = write.

1.4 KiB Raw Blame History