Adds critical build flag

[brendankowitz]

Description

This pull request introduces a new buildCriticalOnly flag to both CI and PR pipelines, allowing the build, deployment, and test stages for R4B and R5 FHIR versions to be skipped when only critical (STU3/R4) validation is needed. This change accelerates hotfix and rapid iteration workflows while preserving the default comprehensive validation. The implementation includes pipeline parameterization, conditional stage execution, and documentation of the approach.

Key changes:

Pipeline Parameterization and Logic:

• Added a buildCriticalOnly boolean parameter (default: false) to build/ci-pipeline.yml, build/pr-pipeline.yml, and the docker-build-all.yml template, enabling selective execution of pipeline stages. [1] [2] [3]
• Applied Azure Pipeline conditions to skip R4B and R5 deployment and test stages when buildCriticalOnly is true in both CI and PR pipelines. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
• Updated Docker build jobs to skip R4B and R5 image builds when buildCriticalOnly is enabled. [1] [2]

Stage Dependencies and Finalization:

• Adjusted dependencies and finalization logic in both pipelines to ensure the correct stages are required for success when running in critical-only mode (e.g., only require STU3/R4 tests to pass when skipping R4B/R5). [1] [2]

Documentation:

• Added a new architecture decision record (docs/arch/adr-2510-critical-build-flag.md) detailing the rationale, implementation, usage guidelines, and consequences of the buildCriticalOnly flag.

Related issues

Addresses [issue #].

Testing

Describe how this change was tested.

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 65 characters
• Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
• Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
• Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
• Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
• When changing or adding behavior, if your code modifies the system design or changes design assumptions, please create and include an ADR.
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)