ci: remove shared temp cleanup from tag release workflows #16
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
The current
rc-release.ymldeletes/tmp/bread-ecosystem-ci-*before creating a fresh clone, which can remove another concurrent release job's checkout.release.ymlalso deletes and reuses the fixed/tmp/bread-ecosystem-cipath, which is shared across runner jobs. Use uniquemktempdirectories in these workflows and remove the shared-path deletion. Keep this scoped to breadpad's release workflow copies. Follow-up to ECO-28.Confirmed the unsafe cleanup on current Forgejo main. Implementation is blocked in this runtime because outbound git SSH is denied:
GIT_SSH_COMMAND='ssh -F /dev/null -o StrictHostKeyChecking=accept-new' git -C /home/breadway/Projects/breadpaper ls-remote origin refs/heads/mainfails withsocket: Operation not permittedto 100.66.238.26:2222. The local PAPER checkout is 16 commits behind main and PAD is 7 commits behind, so I cannot safely base PR branches on current main. MCP provides read-only file access but no branch or push operation. The unsafe paths are identified in the issue body; needs a runtime with Forgejo git push access to make and verify the PR.Confirmed both unsafe release workflow patterns in the local checkout:
rc-release.ymldeletes/tmp/bread-ecosystem-ci-*before using a freshmktempclone, andrelease.ymldeletes and reuses/tmp/bread-ecosystem-ci. This checkout is clean onmainbut seven commits behind current Forgejo main (local origin/main is51aae931; Forgejo reports08aff4a3). I cannot safely create a branch from current main becauseGIT_SSH_COMMAND='ssh -F /dev/null -o StrictHostKeyChecking=accept-new' git ls-remote origin refs/heads/mainfails withsocket: Operation not permittedto 100.66.238.26:2222. Please retry from a runtime with git SSH access; expected change is to remove the wildcard/fixed-path cleanup, clone into uniquemktempdirectories, and clean only each job's own directory.Retried current-main access using the canonical Forgejo SSH endpoint
ssh://git@git.breadway.dev:2222/Breadway/breadpad.git. Fetch command:GIT_SSH_COMMAND='ssh -F /dev/null -o StrictHostKeyChecking=accept-new' git -C ~/Projects/breadpad -c remote.origin.url=ssh://git@git.breadway.dev:2222/Breadway/breadpad.git fetch origin main. It still fails before authentication withsocket: Operation not permitted,ssh: connect to host 100.66.238.26 port 2222: failure, andfatal: Could not read from remote repository.The checkout remains clean onmain, seven commits behind, so I did not create a branch or edit files. PAD-16 remains in TODO until a runtime with Tailscale Forgejo SSH access can fetch current main.This item remains blocked by the documented lack of Forgejo SSH access and a checkout that is behind current main. No branch or PR can be safely created here yet. Moving back to TODO until a current checkout and an allowed push path are available.
Rechecked PAD-16 against current Forgejo state. Main is
08aff4a37a9dd11a2839c9b4b00022cefab622f7; there is no PAD-16 branch or pull request. The shared Breadpad checkout remains clean on main atc671d2e, seven commits behind, and was not changed. A fresh clone in/tmpusing the authorizedssh://git@git.breadway.dev:2222/Breadway/breadpad.gitorigin failed before authentication because SSH rejects/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.confownership/permissions. I stopped without trying another remote or route and did not create a branch. The current Forgejo workflow copies still contain the shared-path deletion patterns. PAD-16 remains blocked in TODO until this runtime can fetch current main through the authorized origin.Implemented and pushed
b4be886on fix/pad-16-isolated-tag-index: #17Both tag workflows now use unique mktemp clone directories with EXIT cleanup limited to their own directory. YAML parsing and shell syntax passed. Four concurrent mocked steps used distinct paths; success and failure cleanup passed, and a sibling active checkout survived. No personal config, desktop, installed binary, release tag, or deployment was touched.