SLING-13253 - update-local-site: shallow-clone the site checkout

[royteeuwen]

Stack: 2 of 2 — builds on #50. Review that first.

Reduced to just the shallow clone: the fixes that were mixed in here have moved down to #50, per review feedback.

The checkout is cloned inside the container, so unless it is pointed at a directory that outlives the run it is re-cloned every time — and a full clone of sling-site is ~380 MB of history against ~15 MB of content. Only the tip of the published branch is ever needed: the content is edited and committed on top of it, never inspected historically. The clone is therefore shallow and single-branch, and the refresh fetch stays shallow so a reused checkout does not grow back into a full clone.

Measured against the real gitbox: 23 MB (8.2 MB .git), one commit, 13 s, down from ~380 MB.

Covered by a test running against a real JGit and two real local repositories rather than mocked git commands: it clones shallowly, refreshes, commits and pushes, so a JGit upgrade that breaks shallow fetches — or a server that refuses a push from a shallow clone — fails here rather than during a release.

Also validated end to end against a real past release (Event Impl 4.4.2): a shallow checkout, reverted to the pre-release state, produced a downloads.tpl byte-identical to the human commit that released it (blob c44750814…), pushed from the shallow clone, with the junk from a deliberately wrong starting branch correctly discarded. The push went to a local repository standing in for gitbox.

Verified: full build green (179 tests).

---

Review order: please look at #50 first — this PR is logically stacked on it, but GitHub will not let me change the base: the now-merged #47 and #40 pin the original stack (Unstacking not allowed: Pull requests #47, #40 cannot be removed from this stack), so this one is locked to master.

Until #50 merges, the diff here therefore shows both commits. Only the second one, 281545c (shallow clone), is what this PR is about; 34b037a is #50. Once #50 lands, this shrinks to the shallow-clone commit alone.

[rombert]

This looks like using shallow clone but otherwise it also has some fixes which should be lower in the stack? In the end I was sort of expecting a different stack

• 1 PR for making the site update work
• 1 PR for integrating it in the finalize command
• any other follow-up PRs for extra functionality on top of that (probably not needed)

[royteeuwen]

Thanks @rombert — you were right that this PR mixed things up. Split as follows:

• SLING-13253 - update-local-site: fix problems found running the website update #50 — the three fixes that were buried in here: ensureRepo resetting whatever branch was checked out, the commit recording root@<container id> as committer, and the false "add it by hand" warning when the downloads entry was already up to date. Plus the JGit filesystem-warning noise.
• this PR — only the shallow clone and the test that covers it.

Both build independently (176 and 179 tests), so the two are reviewable on their own.

On the wider point about the shape of the stack — 1 PR to make the site update work, 1 PR to integrate it into finalize — that one I cannot retrofit: #40 contained both and is already merged, so the split would have had to happen before it went in. Noted for next time; the remaining work is decomposed the way you asked.

One mechanical snag: I could not set this PR's base to #50's branch, because the merged #47 and #40 pin the original stack and GitHub refuses to unstack it (Pull requests #47, #40 cannot be removed from this stack), which also blocks changing the base. So both PRs target master and the diff here shows two commits until #50 merges, after which it shows only 281545c.

[royteeuwen]

Also fixed the remaining concern from reviewing this branch: fetch().setDepth(1) was requested unconditionally, so refreshing a checkout that was not shallow silently truncated its history — git writes .git/shallow and recovering needs --unshallow. Since --site-checkout can point anywhere, that could quietly damage a release manager's own clone of sling-site.

The shallow fetch is now only requested when the checkout is already shallow, so:

• the container's own checkout (cloned shallow here) stays shallow and does not grow back into a full clone;
• a full clone someone points at it keeps its history.

Covered both ways: a new test asserts a full checkout stays full after a refresh (confirmed to fail without the guard — "a full checkout must stay full"), and the existing shallow tests still assert the shallow checkout stays shallow. The README caveat is relaxed accordingly.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
94.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud