Drop a duplicate bundle install and an unshallow…

Details

Read the real build log this time, over the websocket the Netlify UI uses
(wss://socketeer.services.netlify.com/build/logs — the REST API has no log
endpoint, and app.netlify.com/api/v1/deploys/<id>/log returns the SPA shell with
a 200, which is a convincing false positive).
Two things the log showed that guesswork had not:
**`bundle install` ran twice.** "Bundle complete! 2 Gemfile dependencies, 99
gems now installed" appears at line 42, inside Netlify's own initializing
section, and again at line 107 from our command. The build image installs gems
itself when it sees a Gemfile; ours was redundant.
**The unshallow never applied.** Three lines, every build:
    fatal: --unshallow on a complete repository does not make sense
Netlify already does a complete clone. All three fallbacks failed in turn, which
is also the real reason `--filter=blob:none` changed nothing when it was added —
it was dead code, not an ineffective optimisation. It now runs only if the repo
really is shallow, so the fallbacks survive for the day that changes without
printing three fatals when it has not.
Also confirmed from the same log: the `GitHub Metadata: No GitHub API
authentication could be found` warning is GONE now that JEKYLL_GITHUB_TOKEN is
set — the Jekyll section fetches the remote theme with no complaint. The only
remaining matches for that string are our own echo statement inside the printed
command.
Where the 56s went: build.command 28.3s, deploy 4.6s, Netlify Build 33.1s, the
rest queue and cache save. One deprecation remains and is not ours to fix —
Netlify's own bundler call passes `--binstubs`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DAJJ63FFnLoD5XLpu6yJaG

Files changed (1)