Skip to content

ci: manual Aminet upload workflow for failed-publish recovery - #15

Merged
sidick merged 1 commit into
mainfrom
aminet-manual-upload
Jun 13, 2026
Merged

ci: manual Aminet upload workflow for failed-publish recovery#15
sidick merged 1 commit into
mainfrom
aminet-manual-upload

Conversation

@sidick

@sidick sidick commented Jun 13, 2026

Copy link
Copy Markdown
Owner

What

A new .github/workflows/aminet-upload.yml triggered by workflow_dispatch (manual button in the Actions tab, or gh workflow run). Takes a tag input, downloads the versioned lha + readme from that GitHub Release, renames to the unversioned Aminet shape, runs the same sidick/aminet-release-action@v1.

Why

When the automated upload in release.yml fails for a transient reason (FTP timeout, Aminet maintenance, etc.) the current recovery options are:

  • Retag the release and re-run the whole flow -- but that also re-publishes the GitHub Release page with a duplicate of an already-good artefact.
  • Drop to a shell and run lftp by hand against main.aminet.net.

Neither is great. This workflow retries just the Aminet step against an existing release.

Usage

gh workflow run "Aminet upload (manual)" -f tag=v44.0

Or from the GitHub UI: Actions → "Aminet upload (manual)" → Run workflow → enter the tag.

Implementation notes

  • The action's "attach to matching GitHub Release" step is a no-op on workflow_dispatch because GITHUB_REF is the dispatched branch, not the tag. Confirmed by reading the action's _attach_to_release source. Good -- the release page already has its assets, we don't want to re-attach.
  • Files land in $GITHUB_WORKSPACE (via build/ and the repo root) so the action's Docker container can see them; only the workspace is bind-mounted.
  • permissions: contents: read is sufficient -- the workflow never writes to the release or to the repo.

Validation

The three existing CI jobs (host-build, amiga-dist, semgrep) run as usual on this PR -- they don't touch the new workflow. The new workflow itself can only be validated by manually running it after merge against an existing release. Plan: trigger gh workflow run "Aminet upload (manual)" -f tag=v44.0 once merged and watch the log. If there's a bug, fix forward in a follow-up PR.

When the automated Aminet upload in release.yml fails for a transient
reason (FTP timeout, Aminet maintenance window, whatever) you
currently have to either:

  - retag and re-run the whole release flow, which also re-publishes
    the GitHub Release with a duplicate of an already-good artefact, or
  - drop down to a shell and run lftp by hand against main.aminet.net.

Neither is great. Add a workflow_dispatch-triggered job that takes a
tag input, downloads the versioned lha + readme from that GitHub
Release, renames them to the Aminet-shape unversioned form, and runs
the same sidick/aminet-release-action that release.yml uses.

Usage:
  gh workflow run "Aminet upload (manual)" -f tag=v44.0
or click "Run workflow" in the Actions tab UI.

Implementation notes baked into the YAML comments:

  - The action's "attach to matching GitHub Release" step short-circuits
    on workflow_dispatch because GITHUB_REF is the branch, not the tag.
    Exactly what we want -- the release page already has its assets.
  - Files must land inside $GITHUB_WORKSPACE because the action runs in
    Docker and only the workspace is bind-mounted.
  - Permissions: contents: read is enough; we never write to the
    release or to the repo.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@sidick
sidick merged commit 793ed2d into main Jun 13, 2026
3 checks passed
@sidick
sidick deleted the aminet-manual-upload branch June 13, 2026 14:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant