ci(forgejo): guard deploy-stage — main code ≠ stage DB schema
Some checks failed
CI / Web (React + Vite) (push) Waiting to run
CI / POS (WPF, Windows) (push) Waiting to run
CI / Backend (.NET 8) (push) Has been cancelled
Docker Images / API image (push) Successful in 5s
Docker Images / Web image (push) Successful in 6s
Docker Images / Deploy stage (push) Has been skipped

The stage DB is on Phase2c3_MsStrict (vat_rates dropped, etc.), but
main still has Product.VatRateId / DbSet<VatRate> and friends — that
code would blow up at startup against the current DB. The user's
'feat strict MoySklad schema' commit (f7087e9) isn't present in main
any more (looks like a rebase dropped it); the pre-built image with
that SHA is still in the registry and that's what the stage is pinned
to right now.

Until main gets the matching code, deploy-stage should only fire on
tag or manual dispatch — push-to-main still builds images, just
doesn't roll the stage forward.
This commit is contained in:
nurdotnet 2026-04-23 17:10:04 +05:00
parent 41fe088586
commit 6ab8ff00d1

View file

@ -56,6 +56,13 @@ jobs:
name: Deploy stage name: Deploy stage
runs-on: [self-hosted, linux] runs-on: [self-hosted, linux]
needs: [api, web] needs: [api, web]
# Temporary guard: main currently contains references to VatRate etc. while
# the stage DB is already on Phase2c3_MsStrict (vat_rates dropped). Until
# the user lands the matching code changes on main, an auto-deploy of a
# freshly built image from main would break the API. Run deploy only on
# tag/dispatch; normal pushes still build + push images to the local
# registry, but don't roll the stage forward.
if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4