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

2.4 KiB

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.

  • PR#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.