ci: use partial clone for extension dependencies #181
Merged
Florian Ruppel (fruppel) merged 1 commit intoJul 20, 2026
Conversation
Dependency repos (e.g. SwagCommercial) are currently cloned with full
history, which transfers the entire pack on every CI run. Since 2026-07-18
the Downstream workflows fail in 30-50% of runs while cloning
SwagCommercial ('Failed sending HTTP request'), likely due to throttling
of the runner egress IPs caused by the clone volume.
Clone with --filter=blob:none instead: all refs stay available for the
.auto branch checkout, but historic blobs are only fetched on demand,
cutting the transfer size to a fraction.
Florian Ruppel (fruppel)
requested review from
Malte Janz (MalteJanz) and
Nicolas Fortier (nfortier-shopware)
July 20, 2026 10:40
Nicolas Fortier (nfortier-shopware)
approved these changes
Jul 20, 2026
Florian Ruppel (fruppel)
deleted the
fix/setup-extension-partial-clone-deps
branch
July 20, 2026 11:02
Florian Ruppel (fruppel)
changed the title
Florian Ruppel (fruppel)
added a commit
that referenced
this pull request
Jul 20, 2026
) The partial-clone change (#181) did not resolve the intermittent 'Failed sending HTTP request' errors when cloning SwagCommercial: the failures occur within ~60ms, before any pack data is transferred, so transfer volume was not the bottleneck. curl error 55 at that stage is a typical symptom of an HTTP/2 stream reset while the request body is being sent. SwagCommercial's fetch negotiation request is ~15x larger than that of other dependencies (3707 refs vs ~250), which matches it being the only repo affected. None of the involved actions changed when the failures started (2026-07-18), pointing at a runner-image or transport-level change. Retry attempts now force http.version=HTTP/1.1 and enable GIT_CURL_VERBOSE (auth headers are redacted by git). If retries succeed consistently while first attempts keep failing, HTTP/2 is confirmed as the trigger and can be disabled for the first attempt as well; if they keep failing, the verbose log shows where the connection breaks.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Since 2026-07-18, Downstream workflows (e.g. in
shopware/Rufus) fail in 30–50 % of runs while cloningSwagCommercial:Failure rate per hour (Downstream workflow, shopware/Rufus):
All failures have the identical signature: the connection is rejected immediately (all 3 retry attempts fail within ~0.2 s each). SwagCommercial is simply the first dependency in the clone loop, so it always takes the hit. The pattern (instant connection failures, correlated with run volume, self-hosted runners behind shared NAT egress) points to throttling of the runner egress IPs, driven by the volume of full-history clones (~140 MB packed per clone, 30+ runs/hour).
Change
Clone dependencies with
--filter=blob:none(partial clone, lazy blobs):.autobranch resolution and the subsequentgit checkoutkeep working unchanged (verified: branch checkout on a partial clone lazy-fetches the needed blobs transparently, using the same auth extraheader).Notes
path-type repos are unaffected (working tree is fully materialized).vcs-type repos on the cloned path may lazy-fetch blobs on demand; the per-repo auth header set in the clone loop persists for the job, so those fetches authenticate fine.