18 lines
2.3 KiB
Markdown
18 lines
2.3 KiB
Markdown
# Candidate-only upload
|
|
|
|
```sh
|
|
remote backend upload --artifact /path/to/verified-release
|
|
# Optional compatibility flag; upload itself has no interactive prompt:
|
|
remote backend upload -y --artifact /path/to/verified-release
|
|
```
|
|
|
|
The directory must contain the JAR and its exact manifest from a successful build. The command never builds. Local validation checks runtime, full commit and SHA-256 before opening SSH. The existing deployment transport sends only these two files through one SSH connection, retaining its optional pinned identity/host-key support.
|
|
|
|
The server uses the existing nonblocking deployment lock and runtime-layout preflight, refuses an outstanding deployment journal, and calls the same restricted archive staging implementation as deployment. It validates the manifest and checksum again before storing the release under `~/opt/werkjournal/releases/<commit>`. Repeating an identical upload succeeds; different contents for an existing release ID are rejected. Failed staging removes its temporary candidate directory.
|
|
|
|
Successful output is `STAGED`, not a deployment success. Upload does not stop/start the service, run migrations, alter maintenance, copy the database, update `deployed.json` or switch `current`, `previous` or `rollback`. A normal restart continues to use the verified current release.
|
|
|
|
Activate through `remote backend deploy --artifact /path/to/verified-release`. Deployment still checks ancestry and the running manifest, takes its consistent database backup, switches only through its established maintenance/readiness procedure and retains rollback behavior. Upload does not bypass any deployment gate. A later successful deployment may remove unused staged releases during ordinary release cleanup, so retain the original local/CI artifact until activation.
|
|
|
|
Validation: 39 operations tests passed. New tests verify byte-for-byte retained database/manifest/maintenance state, unchanged current release, repeated upload, refusal during pending deployment, checksum rejection and staging cleanup, and later explicit deployment with preserved data and previous release. Transport tests invoke the real upload entry point against a captured SSH process, verify the exact two transferred files and `--upload` mode, and prove local corruption is rejected before SSH. No production upload or restart was required for these tests.
|