Enable incremental build caching in CI pipeline

[frankmueller-msft]

Summary

Cache .tsbuildinfo and .done.build.log files across CI runs to enable TypeScript and fluid-build incremental compilation. First run on a branch builds from scratch and saves the cache; subsequent runs restore the cache and only rebuild what changed.

Changes:

• Add Cache@2 task before the build step with commit-based cache key and OS-level restore key
• Extract cached .tsbuildinfo + .done.build.log files before ci:build; save updated files after
• Enable hash-mode env vars (FLUID_BUILD_ENABLE_*_HASH) for fluid-build tasks that default to mtime-based done file checks (copyfiles, type-validation, good-fences, depcruise)

Why this is safe:

• TypeScript validates .tsbuildinfo files using content hashes, not file mtimes — stale entries cause a rebuild, never silent corruption
• fluid-build's TscTask and TscDependentTask (api-extractor, eslint) also use content hashes in their .done.build.log files
• continueOnError: true on all cache steps — cache failures fall back to a clean build
• Cache key includes $(Build.SourceVersion) so re-runs get exact hits; new commits restore from the OS-level prefix key and TypeScript incrementally rebuilds

Expected impact:

• First run (cold cache): no change (~8m build)
• Subsequent runs (warm cache): ~30-50% build time reduction (~4-5m build)
• Cache size: ~8 MB gzipped

Files changed

File	Change
tools/pipelines/templates/build-npm-client-package.yml	Add Cache@2 + extract/save scripts
tools/pipelines/templates/include-build-lint.yml	Add hash-mode env vars to build step

Test plan

• First CI run completes successfully (cold cache, saves cache artifact)
• Second CI run (re-run or new commit) restores cache and build time decreases
• Cache extraction failure does not block the build (continueOnError)
• All existing tests continue to pass

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Enables incremental build caching in the CI pipeline by persisting TypeScript .tsbuildinfo and fluid-build .done.build.log files between runs, aiming to reduce rebuild time on subsequent CI executions.

Changes:

• Add Azure Pipelines Cache@2 restore step and Bash extract step before the build, and a Bash save step after the build to persist incremental artifacts.
• Set FLUID_BUILD_ENABLE_*_HASH environment variables in the build step to use content-hash based donefile checks for specific fluid-build tasks.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
tools/pipelines/templates/include-build-lint.yml	Adds env vars to enable hash-based incremental checks for selected fluid-build tasks during the build step.
tools/pipelines/templates/build-npm-client-package.yml	Adds restore/extract/save steps around the build to cache .tsbuildinfo and .done.build.log files across CI runs.

[Copilot]

The cache key is effectively unique per commit due to $(Build.SourceVersion), which will create a new cache entry for every commit (and still restore from the broad OS restoreKey). Over time this can cause cache churn/evictions and unnecessary uploads. Consider keying off stable inputs instead (e.g., include ${{ parameters.buildDirectory }} plus a hashed file like pnpm-lock.yaml / package-lock.json and optionally other build config files), so the cache only rolls when relevant inputs change while still enabling incremental rebuilds across commits.

Suggested change

	key: 'tsc-cache | "$(Agent.OS)" | $(Build.SourceVersion)'
	key: 'tsc-cache | "$(Agent.OS)" | $(Pipeline.Workspace)/${{ parameters.buildDirectory }}/package.json'

[Copilot]

These hash-mode env vars are only set on the build (ci:build) step. Since the pipeline also runs npm run lint (which in this repo typically invokes fluid-build --task lint), lint-time tasks like good-fences/depcruise/type-validation may still fall back to mtime-based done files and won’t benefit from the restored cache. Consider setting the same FLUID_BUILD_ENABLE_*_HASH variables on the lint step as well for consistent incremental behavior.

[frankmueller-msft]

Closing this PR — the tsbuildinfo caching approach doesn't work for CI builds.

Root cause: fluid-build's TscTask.checkLeafIsUpToDate() only validates source file hashes against the tsbuildinfo. When all hashes match, it skips tsc entirely — but on a fresh CI agent the build outputs (lib/, dist/, .d.ts) don't exist, causing downstream TS2307: Cannot find module errors.

What we tried:

1. Cache@2 — can't bootstrap new cache types (post-job save requires an existing restore key hit)
2. Pipeline artifacts with tsbuildinfo + done files — stale done files caused TS2344 type validation errors after version bumping
3. Pipeline artifacts with tsbuildinfo only — fluid-build skips tsc for "up to date" packages whose outputs don't exist

Why full build output caching won't help either: "Set Package Version" modifies packageVersion.ts in most packages, invalidating the cached tsbuildinfo for those packages anyway.

Build speed improvements are better pursued via:

• PR ci: split DDS coverage shards and parallelize merge-tree farm tests #26586 — coverage shard splitting (saves ~5 min, already passing)
• Issue ci: skip redundant CJS api-extractor lint checks in ci:build #26592 — moving CJS api-extractor checks off the PR critical path