fix: unshallow git history before Lunaria build to prevent CI failures on new docs

[Copilot]

Summary

Fixes a subset of frontend-build PR CI failures where Lunaria cannot retrieve git history for a newly added docs page during the /i18n build.

Observed behavior

The failure looks like:

Failed to retrieve last commit data from /home/runner/work/aspire.dev/aspire.dev/src/frontend/src/frontend/src/content/docs/...mdx.

What we confirmed

• This does not happen on every PR.
• The doubled src/frontend/src/frontend path is Lunaria's shallow-repo fallback path.
• The failing cases so far are recent PRs that add a brand-new docs page, where Lunaria needs git history for a file that does not exist on the base branch.
• On a PR merge checkout (refs/pull/N/merge), git fetch --unshallow restores the missing history for those files.

Root cause

When @lunariajs/starlight sees a shallow repository, it calls Lunaria's handleShallowRepo() path. That path clones repository history and prefixes repository.rootDir before file history lookups. For a docs page that only exists on the PR branch, that fallback cannot resolve history from main, so the build exits during /i18n.

The doubled path is a symptom of that fallback path, not a separate bug.

Fix

Add this step immediately after actions/checkout in frontend-build.yml:

- name: Ensure full git history for Lunaria
  run: git fetch --unshallow 2>/dev/null || true

The important distinction is that we must fetch the missing history, not just clear the shallow marker.

Impact

• Fixes the recent PR-only Lunaria failures we observed on newly added docs pages.
• Leaves already-full checkouts unchanged.
• Minimal overhead.

[IEvangelist]

Hey @copilot, I'm confused - how is this different than fetch-depth: 0

[Copilot]

Hey @copilot, I'm confused - how is this different than fetch-depth: 0

Great question. They're subtly different in practice.

fetch-depth: 0 tells actions/checkout to fetch all reachable history, but for PR merge refs (refs/pull/N/merge — the synthetic merge commit GitHub creates for CI), the checkout action can still leave the .git/shallow file in place from its internal initial-fetch step. The result: git rev-parse --is-shallow-repository still returns true even after the checkout completes.

This is observable right here in this sandbox — the repo was checked out with fetch-depth: 0 but is still shallow:

$ git rev-parse --is-shallow-repository
true
$ cat .git/shallow
2b3675a75e5ff997e47feb331f7bd0bccad5d56d
$ git log --oneline | wc -l
2

git fetch --unshallow explicitly removes all shallow constraints (clears .git/shallow) so isShallowRepo definitively returns false. Without it, Lunaria detects isShallowRepo=true, clones the public main branch from GitHub, and uses that clone for git history lookups — which naturally has no knowledge of files added only in the PR branch, causing the failure.

[IEvangelist]

Follow-up to the earlier root-cause explanation: we verified that the previous comment overstated the scope. This is not "all PRs" and it is not just a generic fetch-depth: 0 problem by itself.

What we found:

• The failure shows up on a subset of recent PR CIs, especially when a PR adds a brand-new docs page and Lunaria needs git history for that file.
• The correct fix is still the real fetch-based step in this PR: git fetch --unshallow 2>/dev/null || true.
• The later docs/environments-guide commit 17650988 (Clear shallow marker for frontend build) regressed that by replacing the fetch with rm .git/shallow.

Those two commands are not equivalent. In a simulated refs/pull/705/merge checkout:

• git fetch --unshallow restored history for src/frontend/src/content/docs/deployment/environments.mdx
• deleting .git/shallow only hid the marker and left Git unable to walk history correctly

That explains why PR #705 could still fail even though this PR's approach is directionally correct.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Ensures the frontend-build workflow has a non-shallow git checkout so Lunaria can resolve commit history for newly added docs files, preventing CI failures on PRs.

Changes:

• Adds a post-checkout git fetch --unshallow step to force a full history in CI when needed.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Redirecting all stderr to /dev/null and then forcing success with || true can hide real fetch failures (e.g., network/auth/remote issues), making CI logs misleading and harder to debug. Prefer an explicit shallow-check gate (e.g., read git rev-parse --is-shallow-repository) and only run git fetch --unshallow when needed, while allowing unexpected errors to surface (or at least logging them). If cross-runner portability matters, also consider ensuring a bash shell is used (since 2>/dev/null is shell-specific).

Suggested change

	run: git fetch --unshallow 2>/dev/null || true
	shell: bash
	run: |
	if [[ "$(git rev-parse --is-shallow-repository)" == "true" ]]; then
	git fetch --unshallow
	else
	echo "Repository already has full git history."
	fi