🙋 Feature Request
CI pipelines currently run the full build and test suite for every pull request, including PRs that only modify documentation files (markdown, specs, issue templates, etc.). This wastes CI resources and delays PR merges for changes that cannot affect build or test outcomes.
🤔 Expected Behavior
When a pull request only contains changes to documentation files, CI pipelines should skip the expensive build, test, and validation steps. The following file patterns should be treated as documentation-only:
**/*.md — all markdown files (READMEs, changelogs, contributing guides)
LICENSE
specs/** — design specifications
.github/ISSUE_TEMPLATE/**, .github/skills/** — GitHub configuration and templates
Lightweight validation steps (beachball checkchange, Prettier format:check) should still run on every PR regardless of what files changed, to ensure change files are present and formatting is correct.
PRs that modify both documentation and source files should continue to run the full pipeline.
😯 Current Behavior
All three CI pipelines run unconditionally on every push and pull request to main:
azure-pipelines-ci.yml — Azure DevOps CI (install, build)
.github/workflows/ci-validate-pr.yml — GitHub Actions PR validation (install, checkchange, format, build, Playwright tests)
.github/workflows/ci-validate-platforms.yml — GitHub Actions cross-platform/cross-browser validation (install, format, build, Playwright tests on Linux/Windows/macOS)
A documentation-only PR (e.g., fixing a typo in a README) triggers the full matrix of builds and test runs, which can take several minutes across multiple agents.
💁 Possible Solution
Use a tiered approach based on what each pipeline is responsible for:
ci-validate-pr.yml: Always trigger the workflow, but add a change-detection step that checks whether any non-documentation files were modified. Run checkchange and format:check unconditionally, then gate the build, Playwright install, and test steps behind the change-detection output. This ensures beachball validation still runs for documentation PRs that touch packages.
ci-validate-platforms.yml: Use paths-ignore on both push and pull_request triggers. This pipeline doesn't run checkchange, so skipping it entirely for doc-only changes is safe.
azure-pipelines-ci.yml: Use paths.exclude under the pr trigger to skip the pipeline for doc-only changes.
- Keep
workflow_dispatch and schedule triggers unfiltered so manual and scheduled runs always execute the full suite.
- The
cd-gh-pages.yml and azure-pipelines-cd.yml pipelines do not need changes since they are already scoped to manual dispatch or scheduled triggers.
🔦 Context
The sites/website/ package consumes API documentation generated from TypeScript compilation artifacts (.api.json files), not raw markdown. Changes to markdown files in packages/ (e.g., README updates) do not affect the website build output or any package build. This makes it safe to skip build and test steps for markdown-only changes without risking missed regressions.
The ci-validate-pr.yml workflow uses conditional steps rather than paths-ignore because beachball's ignorePatterns do not currently exclude *.md files. A documentation change inside a package directory would still require a change file, so the checkchange step must always run.
🙋 Feature Request
CI pipelines currently run the full build and test suite for every pull request, including PRs that only modify documentation files (markdown, specs, issue templates, etc.). This wastes CI resources and delays PR merges for changes that cannot affect build or test outcomes.
🤔 Expected Behavior
When a pull request only contains changes to documentation files, CI pipelines should skip the expensive build, test, and validation steps. The following file patterns should be treated as documentation-only:
**/*.md— all markdown files (READMEs, changelogs, contributing guides)LICENSEspecs/**— design specifications.github/ISSUE_TEMPLATE/**,.github/skills/**— GitHub configuration and templatesLightweight validation steps (beachball
checkchange, Prettierformat:check) should still run on every PR regardless of what files changed, to ensure change files are present and formatting is correct.PRs that modify both documentation and source files should continue to run the full pipeline.
😯 Current Behavior
All three CI pipelines run unconditionally on every push and pull request to
main:azure-pipelines-ci.yml— Azure DevOps CI (install, build).github/workflows/ci-validate-pr.yml— GitHub Actions PR validation (install, checkchange, format, build, Playwright tests).github/workflows/ci-validate-platforms.yml— GitHub Actions cross-platform/cross-browser validation (install, format, build, Playwright tests on Linux/Windows/macOS)A documentation-only PR (e.g., fixing a typo in a README) triggers the full matrix of builds and test runs, which can take several minutes across multiple agents.
💁 Possible Solution
Use a tiered approach based on what each pipeline is responsible for:
ci-validate-pr.yml: Always trigger the workflow, but add a change-detection step that checks whether any non-documentation files were modified. Runcheckchangeandformat:checkunconditionally, then gate the build, Playwright install, and test steps behind the change-detection output. This ensures beachball validation still runs for documentation PRs that touch packages.ci-validate-platforms.yml: Usepaths-ignoreon bothpushandpull_requesttriggers. This pipeline doesn't runcheckchange, so skipping it entirely for doc-only changes is safe.azure-pipelines-ci.yml: Usepaths.excludeunder theprtrigger to skip the pipeline for doc-only changes.workflow_dispatchandscheduletriggers unfiltered so manual and scheduled runs always execute the full suite.cd-gh-pages.ymlandazure-pipelines-cd.ymlpipelines do not need changes since they are already scoped to manual dispatch or scheduled triggers.🔦 Context
The
sites/website/package consumes API documentation generated from TypeScript compilation artifacts (.api.jsonfiles), not raw markdown. Changes to markdown files inpackages/(e.g., README updates) do not affect the website build output or any package build. This makes it safe to skip build and test steps for markdown-only changes without risking missed regressions.The
ci-validate-pr.ymlworkflow uses conditional steps rather thanpaths-ignorebecause beachball'signorePatternsdo not currently exclude*.mdfiles. A documentation change inside a package directory would still require a change file, so thecheckchangestep must always run.