63 lines
2.8 KiB
Gherkin
63 lines
2.8 KiB
Gherkin
Feature: Reproducible releases with recoverable data
|
|
@WJ-020 @production_smoke
|
|
Scenario: Production JAR smoke check
|
|
Given the full JVM test suite has passed
|
|
When the production JAR starts with isolated test configuration
|
|
Then the process starts successfully
|
|
And its readiness endpoint becomes reachable
|
|
And no production notification is sent
|
|
|
|
@WJ-021 @deployment
|
|
Scenario: Roll back a partially failed migration
|
|
Given a known-good release with a fresh consistent pre-deployment backup
|
|
When a candidate migration fails after modifying part of the schema
|
|
Then the candidate process is stopped
|
|
And the matching database backup and known-good executable are restored
|
|
And public access remains in maintenance until readiness succeeds
|
|
|
|
@WJ-022 @deployment
|
|
Scenario: Preserve known-good state across two failed releases
|
|
Given release A is running successfully
|
|
And a new work entry was saved after A was deployed
|
|
When candidates B and C fail in consecutive deployments
|
|
Then A remains the known-good executable
|
|
And the new work entry is still present after each rollback
|
|
And neither B nor C replaces the successful rollback target
|
|
|
|
@WJ-023 @deployment
|
|
Scenario: Keep maintenance active after a failed rollback
|
|
Given a deployment fails
|
|
When restoration cannot pass readiness checks
|
|
Then the public maintenance page remains active
|
|
And the pipeline records deployment and rollback failure
|
|
|
|
@WJ-024 @operator_restore
|
|
Scenario: Restore from a Hostsharing backup
|
|
Given a representative saved database and its application version
|
|
When the operator follows the restore procedure in an isolated environment
|
|
Then the database opens with a consistent migration state
|
|
And expected work entries and historical limits are present
|
|
And reminder sending remains disabled until explicitly released
|
|
|
|
|
|
@WJ-025 @deployment
|
|
Scenario: Upload does not activate an unverified candidate
|
|
Given release A is the known-good release
|
|
When the operator uploads candidate B using tools/remote
|
|
And restarts the service without deploying B
|
|
Then release A remains active
|
|
|
|
@WJ-026 @deployment
|
|
Scenario: CI deploys the exact tested artifact
|
|
Given a main-branch artifact has passed the required checks
|
|
When CI invokes tools/remote with that artifact in non-interactive mode
|
|
Then deployment does not rebuild the application
|
|
And the deployed commit matches the tested artifact manifest
|
|
|
|
@WJ-027 @deployment
|
|
Scenario: A failed deployment remains failed after successful rollback
|
|
Given tools/remote is deploying a candidate
|
|
When the candidate fails readiness and rollback succeeds
|
|
Then tools/remote returns a nonzero exit code
|
|
And its log records the candidate failure and successful recovery
|