Build Types

📖 Build Types in CI/CD Pipeline

This page explains how build types are determined and used in the CI/CD pipeline. Build types control how the system interprets incoming events, what kind of build or release it should execute, and what outputs are produced.

The system supports three main build types:

Build Type	Description
preview	For development, preview, or test builds (non-production)
release_candidate	For staging builds, e.g., v1.2.3-rc.1
release	For final production releases, e.g., v1.2.3

---

🔍 How Build Type Is Determined

The pipeline resolves the build type in the following order:

---

1️⃣ Tests-only Override

If the pipeline is run with TESTS_ONLY=true,
✅ it always forces buildType=preview.

This ensures that test-only runs don’t accidentally trigger release or candidate pipelines.

---

2️⃣ Manual Override

If a manual override is provided via input (BUILD_TYPE_OVERRIDE),
✅ it is accepted only if it’s one of:

• preview
• release_candidate
• release

Invalid or unsupported types are not allowed
because workflows are only dispatched by explicit, validated choice
(e.g., through a manual dispatch form with dropdowns or options).
This guarantees no accidental or invalid values go in.

---

3️⃣ Automatic Detection (from event + ref)

When no manual override is present, the pipeline inspects the GitHub event type and git ref:

GitHub Event	Git Ref Pattern	Resolved Build Type
pull_request	(any)	preview
push	refs/tags/vX.Y.Z (e.g., v1.2.3)	release
push	refs/tags/vX.Y.Z-rc.N (e.g., v1.2.3-rc.1)	release_candidate
push	anything else (branch pushes, etc.)	preview
other events	(fallback)	preview

This ensures:

• Pull requests always run as previews.
• Tagged pushes (matching version or RC patterns) trigger releases.
• Regular branch pushes default to previews.

---

⚠️ Semantic Versioning (SemVer) Requirements

The system requires SemVer-compliant tags for releases and release candidates:

✅ Release Tags:

• Must follow vX.Y.Z (e.g., v1.2.3)

✅ Release Candidate Tags:

• Should ideally follow vX.Y.Z-rc.N (e.g., v1.2.3-rc.1)
• If you dispatch only v1.2.3 and set release_candidate as the build type,
  the system can automatically calculate the -rc.N suffix internally.

This allows flexible RC pipelines without requiring the exact RC tag to be inserted.

---

💡 Example Use Cases

✅ Preview Build (Pull Request)
A developer opens a pull request → buildType=preview

✅ Preview Build (Manual Dispatch)
A developer manually dispatches the workflow
and explicitly selects preview from the buildType dropdown → buildType=preview

✅ Release Candidate (Manual Dispatch)
A developer manually dispatches the workflow
with buildType=release_candidate and base version v2.0.0 → system calculates v2.0.0-rc.N

✅ Release Candidate (Tag Push)
A tag like v2.0.0-rc.3 is pushed → buildType=release_candidate

✅ Final Release (Manual Dispatch)
A developer manually dispatches the workflow
with buildType=release and version v2.0.0 → buildType=release

✅ Final Release (Tag Push)
A tag like v2.0.0 is pushed → buildType=release

---

💬 Questions?

If you’re unsure which build type your workflow will resolve to, check:

• The workflow logs → look for the Resolved build type log line. In the dispatcher, you'll find it in the Prepare Metadata workflow.
• The value of $BUILD_TYPE or $buildType in later workflow steps.