bug: Woodpecker CI clone fails with TLS EOF on Tailscale funnel #107
Labels
No labels
domain:backend
domain:devops
domain:frontend
status:approved
status:in-progress
status:needs-fix
status:qa
type:bug
type:devops
type:feature
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
forgejo_admin/pal-e-platform#107
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?
Lineage
plan-pal-e-platform— platform reliabilityRepo
forgejo_admin/pal-e-platformUser Story
As a developer
I want CI pipelines to clone reliably
So that merges deploy without manual retries
Context
During the westside Phase 15 session (2026-03-18), every Woodpecker CI pipeline required 2-3 retries due to TLS clone failures. The error is consistent:
Affected repos:
basketball-api(pipelines #22-28),pal-e-platform(pipeline #108). The clone step fetches via HTTPS through the Tailscale funnel. Some runs clone successfully on retry, suggesting an intermittent TLS termination issue — not a permanent misconfiguration.Observations
git fetch --filter=tree:0(partial clone) — the promisor remote fetch fails mid-streamPossible Causes
--filter=tree:0(partial clone) which requires multiple round-tripsFile Targets
Acceptance Criteria
Test Expectations
Constraints
Checklist
Related
plan-pal-e-platform— platform hardeningsop-ci-pipeline-recovery— current workaround is manual retrySession Findings (2026-03-18)
The TLS fix applied in the previous session only helps server API calls — the git clone step uses a different TLS code path and still fails. Clone succeeds for pal-e-platform but fails for basketball-api and likely other repos.
Why pal-e-platform works but others don't
Needs investigation. Possible difference: pal-e-platform uses the
forgejoremote name, other repos useorigin. Could also be a cert chain issue specific to certain Tailscale funnel paths.Options (from previous session)
.woodpecker.yamlthat uses the internal Forgejo URL (http://forgejo-http.forgejo.svc.cluster.local:80)Impact
This blocks:
Recommended approach
Option 1 (custom clone step) is the lowest-risk immediate fix. Option 3 (debug funnel TLS) is the proper root cause investigation. Both can be parallelized.