PullRepo fetches the remote twice per pull (fetch --all --prune, then git pull --rebase), and the first fetch is never logged
What happened
Expected: one PullRepo contacts the remote once.
Actual: it contacts the remote twice, and the first of the two costs 0.7 to 1.1 s per pull even when nothing changed.
Reading lib/git/src/pull.rs, the stage order is Set Git Remote, then git fetch --all --prune, then Checkout branch, then git pull --rebase --force origin <branch>. The last command performs its own fetch against the same remote, so the explicit fetch is repeated a few hundred milliseconds later as part of the pull.
Separately, the explicit fetch's log entry is only pushed to the response on failure (if !fetch.success { res.logs.push(fetch); return Ok(res); }). On the success path no stage names it, so in the Komodo UI and in ListUpdates output the time shows up as an unexplained gap between Set Git Remote and Checkout branch rather than as a stage.
Steps to reproduce
- Configure a Repo resource against a remote git host (GitHub in our case).
- Run
PullRepoon it twice in a row, so the second run has nothing to pull. - Read the update's stage timestamps: there is a gap between
Set Git RemoteandCheckout branchwith no stage of its own. - In the Periphery container, in that same clone, time
git fetch --all --pruneby hand and compare it to the gap.
Logs / error output
Measured inside komodo-periphery, in the live clone, with start and end timestamps written to files either side of the call:
git fetch --all --prune 0.724 s
git fetch origin main --prune 0.681 sStage gaps between Set Git Remote and Checkout branch across the three pulls of one procedure run: 1.143 s, 0.973 s, 0.726 s.
Narrowing the fetch to the single deployed branch makes no measurable difference, and the clone carries 25 remote branches, so branch count is not the cost. Explicit protocol v2 makes no difference either (already the default). The network to github.com from this host is fast: curl -w reports TLS handshake 26 ms, TTFB 42 ms, total 90 ms. GIT_TRACE=1 places the time inside git's own fetch, before its post-fetch hooks (rev-list --objects, maintenance run --auto) start, so it is the upload-pack negotiation with the remote.
Environment
- Komodo Core version (
GetVersion): 2.3.3 - Komodo Periphery version: 2.3.3
- Install method: Docker
- OS / arch: Linux 6.18.38-Unraid x86_64
- git version in the Periphery image: 2.47.3
- Repo remote: github.com over HTTPS, 25 remote branches
Source: moghtech/komodo