github CodesWhat/drydock v1.6.1-rc.5

latest release: v1.7.0-rc.5
pre-release3 hours ago

v1.6.1-rc.5

Full Changelog: v1.6.1-rc.4...v1.6.1-rc.5

[1.6.1-rc.5] — 2026-08-27

Fixed

  • Compose updates now pick up runtime defaults the new image ships. A container recreated by the compose action was rebuilt from the stored config rather than re-reading the defaults baked into the pulled image, so anything the image sets for itself — APP_VERSION, RELEASE_VERSION and the like — carried over from the old container and made the UI keep reporting an update while the running image was already current. A manual docker compose down && docker compose up -d fixed it because compose rebuilds that config from the image every time. Backported from the v1.7 line, where the reporter's version could not reach it. (#734, #736)
  • The Crowdin translation-sync workflow failed on every push to dev/v1.6 while a newer dev/v1.7 branch also existed on origin, dying with Your local changes to the following files would be overwritten by checkout. The base-branch resolver always targeted the highest dev/vX.Y branch on origin regardless of which branch triggered the run, but the crowdin action had already downloaded translations into the working tree by the time that step ran, so checking out a different branch over those changes failed. A push straight to a dev/vX.Y branch now targets that branch directly as the base instead of going through the highest-wins lookup; scheduled and workflow_dispatch runs are unaffected and keep using it. (#906)
  • The Crowdin sync job could push its l10n_crowdin branch but never open the pull request. GitHub Actions' ambient GITHUB_TOKEN is blocked from creating pull requests in this repo (can_approve_pull_request_reviews is false org-wide), so the crowdin action's PR-creation call 403'd with GitHub Actions is not permitted to create or approve pull requests right after the translations had already been pushed, leaving them stranded on l10n_crowdin with no PR to review. The job now mints a short-lived GitHub App installation token via actions/create-github-app-token and authenticates the PR-creation step with that instead, matching the fix already on dev/v1.7. (run 33126469987)
  • The portwing fleet-soak workflow declared a 90-day artifact retention the repo doesn't actually allow. The org's artifact-and-log retention ceiling is 30 days, so GitHub was silently clamping the retention-days: 90 on the soak-evidence upload and the file misreported how long that evidence really survives. Corrected to 30, matching dev/v1.7.

Note: this is a maintenance cut, built from dev/v1.6 at 60f996dbf1aaf7de17fd67e59f1a9e92d1c0ebea, not from main.

  • The container image and release artifact are cosign-signed (identity release-cut.yml@refs/heads/main, since the workflow run itself always executes at that ref), but carry no SLSA build-provenance attestation — this workflow's own OIDC token always claims main HEAD as the build source, which would be false for this artifact, so attestation is skipped rather than publish a false claim.

Don't miss a new drydock release

NewReleases is sending notifications on new releases.