Files
werkrevisor/docs/prs/2026-10-10-PR#70-deploy-one-connection.md
claude-code d67a807abc
werkator build succeeded after 00:10
werkator/werkrevisor-statistics build succeeded after 00:27
werkrevisor 0.31.4: deploy-rootfs needs two connections and retries a refused one (#70)
Co-authored-by: claude-code <claude-code@javagil.de>
2026-10-10 07:48:42 +02:00

61 lines
2.4 KiB
Markdown

# PR#70: tools/deploy-rootfs Needs Two Connections and Retries a Refused One
> **WARNING:** This document describes only the change applied in this PR.
> It may already be outdated once the next PR is merged.
> Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.
## Related Links
- [PR#69](https://git.javagil.de/mi/werkrevisor/pulls/69): release tools keep only the two newest archives.
## The Problem
The first deploy with `tools/deploy-rootfs` of PR#69 uploaded 0.31.3 and switched all four repositories on mih09.
Then the host refused the next ssh connections, so the script removed no old archive.
It opened eight connections in a row: the upload, the checksum, one per repository, and three for the cleanup.
The webspace refuses connections that follow too quickly.
## Non-Goals
- No change to what the script deploys, keeps or removes.
## The Scenarios
### Feature: a deploy survives a host that refuses quick connections
#### Scenario#70.01: the deploy opens only two connections
So that the host has no reason to refuse one.
- **Given** an archive and four repositories on one host
- **When** the deploy runs
- **Then** it connects to the host twice: once for the upload and once for all other steps
##### Verified by
- A test against a local directory instead of a host, with `scp` and `ssh` replaced by local commands:
the archive in use by a second repository stays, the two newest archives stay,
a backup without a version stays, and a second deploy keeps the first backup.
#### Scenario#70.02: a refused connection is tried again
So that a short block of the host does not leave a half-finished deploy.
- **Given** a host that refuses the first connections of a deploy
- **When** the deploy runs
- **Then** it waits 30, 60, 90, 120 and 150 seconds before the next attempts
- **And** it gives up after the sixth refused attempt
##### Verified by
- A run against mih09 after the host had refused the first deploy: it switched four repositories,
removed one archive and 44 backups, and was not refused.
- A local run of `retrying` with a command that always fails: it waits 30 to 150 seconds and then gives up.
## The Solution
- The remote steps run as one script, sent as an argument of a single ssh call,
so that a retry sends it again; it carries `tools/release_files.py` along.
- `retrying` repeats `scp` and `ssh` after a refused connection, up to six times.
- Version 0.31.4.