morningman opened a new pull request, #4080: URL: https://github.com/apache/doris-website/pull/4080
## Problem `scripts/last-update/generate.js` needs full git history — in a shallow clone every file collapses to the HEAD commit, so it exits 1 rather than write a misleading map. Cron Deploy checks out shallow, so it could never run the generator. The published "last updated" footers were whatever the last manual **Refresh Docs Last-Update Map** PR had committed into `scripts/last-update/data.json`, and drifted further behind `master` until someone remembered to trigger that workflow again. ## Change `.github/workflows/cron-deploy-website.yml`: - Checkout now fetches full history with `filter: blob:none`. `actions/checkout@master` is pinned to a **July 2020** commit (v2.3.1-era) that predates the `filter` input, hence the bump to `v4`. - A new step regenerates `data.json` before the build. The build is the only consumer — nothing is committed, so the checked-in map stays the local-build copy and the deploy's fallback. ## Cost Measured against `apache/doris-website`, both over the same link: | | time | size | |---|---|---| | `--filter=blob:none` full history (**added** by this PR) | 12.5s | 21 MB | | `--depth=1` (what the workflow **already** downloads) | 5m40s | 449 MB | The expensive part is the HEAD blobs — images and static assets — and this PR does not touch that path. Full commit history is only ~5% more bytes on top, and a GitHub runner is far better connected than the machine those numbers came from. The generator itself runs in ~1s and uses only Node built-ins, so it needs no `yarn install`. ## Failure behavior The refresh step is deliberately non-fatal. `generate.js` writes `data.json` only after computing everything, so a failure leaves the committed map intact and the deploy still ships with the previous timestamps. A cosmetic footer should not be able to block a release; the step emits a `::warning::` instead. ## Notes - **Refresh Docs Last-Update Map** is kept. The published site no longer depends on it, but it keeps the committed fallback — what local builds read — from drifting far behind. Comments in both workflows were updated to say so. - `manual-deploy-website.yml` is **not** changed. It still checks out shallow and will deploy the committed timestamps, which is exactly what it does today, so this is not a regression. Happy to apply the same two changes there if reviewers want them consistent. - The other edits are comment-only, correcting three places that claimed the deploy renders these dates "without a full-history clone". 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_013F7zebd8iJKbAJB2RSB8iq -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
