sneak/lora.vegas
1
0
Fork 0
Code Issues 11 Pull Requests Actions Packages Projects Releases Wiki Activity

Artifact actions are pinned on v3 because v4 fails on this Gitea Actions instance #20

New Issue
Open
opened 2026-08-09 05:04:29 +02:00 by clawbot · 0 comments
clawbot commented 2026-08-09 05:04:29 +02:00
Collaborator
Copy Link

Split out of #7 so the constraint is tracked rather than buried in a workflow
comment.

What was measured

.gitea/workflows/deploy.yml pins actions/upload-artifact and
actions/download-artifact on the v3 line, not v4. #7's definition of done
asked for v4 (v3 is deprecated upstream). v4 was implemented, merged, and broke
the deploy on main; the second attempt measured why by running the jobs on a
branch.

Observed on branch pin-deploy-refs-observable, commit 2d328e7, via the
commit-status API:

probe / p2-alpine-apk-checkout    success   5s    checkout only
probe / p4-alpine-apk-upload      failure  11s    same job + upload-artifact v4

The two jobs are identical except for a trailing actions/upload-artifact v4
step. Every v3 build tested passes on the same runner and image:

probe / q1-upload-v3-node16       success   7s    v3.2.1     (ff15f030)
probe / q2-upload-v3-node20       success  22s    v3.2.1-n20 (c24449f3)
probe / q3-build-for-roundtrip    success  11s    v3.2.2-n20 (c6a3b2bd)

and both v3 pairs round-trip an artifact across job containers:

probe / r2a-upload-proven / r2b-download-proven    success  12s / 2s
probe / r3a-upload-node20 / r3b-download-node20    success   8s / 2s

So this is not a musl problem, not an image problem, and not a node-runtime
problem. Artifacts v4 is a different wire protocol from v3, and this
Gitea/act_runner deployment does not serve it. (Server is Gitea 1.25.4; the
runner version is not readable from this account.)

Why this is a real item and not just a note

v3 of both actions is deprecated upstream and will stop receiving fixes. The
repo is pinned by SHA either way, so nothing is mutable, but it is pinned to
a line that upstream has abandoned.

Done when

Either:

  • the artifact v4 protocol works on this instance (runner and/or Gitea
    upgrade), deploy.yml moves to v4 pinned by SHA, and a branch run proves the
    upload and download both pass; or
  • it is decided that v3 pinned by SHA is the permanent answer here, and the
    workflow comment plus REPO_POLICIES.md say so explicitly.

Verifying this needs the same technique #7 used: a temporary branch trigger on
on.push.branches plus the if: github.ref_name == 'main' guard on the deploy
job, so the build job runs for real without touching Cloudflare.

Split out of #7 so the constraint is tracked rather than buried in a workflow comment. ## What was measured `.gitea/workflows/deploy.yml` pins `actions/upload-artifact` and `actions/download-artifact` on the **v3** line, not v4. #7's definition of done asked for v4 (v3 is deprecated upstream). v4 was implemented, merged, and broke the deploy on `main`; the second attempt measured why by running the jobs on a branch. Observed on branch `pin-deploy-refs-observable`, commit `2d328e7`, via the commit-status API: ``` probe / p2-alpine-apk-checkout success 5s checkout only probe / p4-alpine-apk-upload failure 11s same job + upload-artifact v4 ``` The two jobs are identical except for a trailing `actions/upload-artifact` v4 step. Every v3 build tested passes on the same runner and image: ``` probe / q1-upload-v3-node16 success 7s v3.2.1 (ff15f030) probe / q2-upload-v3-node20 success 22s v3.2.1-n20 (c24449f3) probe / q3-build-for-roundtrip success 11s v3.2.2-n20 (c6a3b2bd) ``` and both v3 pairs round-trip an artifact across job containers: ``` probe / r2a-upload-proven / r2b-download-proven success 12s / 2s probe / r3a-upload-node20 / r3b-download-node20 success 8s / 2s ``` So this is not a musl problem, not an image problem, and not a node-runtime problem. Artifacts v4 is a different wire protocol from v3, and this Gitea/`act_runner` deployment does not serve it. (Server is Gitea 1.25.4; the runner version is not readable from this account.) ## Why this is a real item and not just a note v3 of both actions is deprecated upstream and will stop receiving fixes. The repo is pinned by SHA either way, so nothing is *mutable*, but it is pinned to a line that upstream has abandoned. ## Done when Either: - the artifact v4 protocol works on this instance (runner and/or Gitea upgrade), `deploy.yml` moves to v4 pinned by SHA, and a branch run proves the upload and download both pass; or - it is decided that v3 pinned by SHA is the permanent answer here, and the workflow comment plus `REPO_POLICIES.md` say so explicitly. Verifying this needs the same technique #7 used: a temporary branch trigger on `on.push.branches` plus the `if: github.ref_name == 'main'` guard on the deploy job, so the build job runs for real without touching Cloudflare.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bot
Agent's turn to work
 merge-ready
Review passed; ready to merge
 needs-checks
PR awaiting green checks
 needs-rebase
PR needs rebase onto main
 needs-review
PR awaiting adversarial review
 needs-rework
Review failed; PR needs rework
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
clawbot sneak
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/lora.vegas#20
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?