本文由 AI 分析生成
建立時間： 2026-03-28 來源： https://chengweichen.com/2024/01/why-use-gitlab-ci-components.html
Summary
Cheng Wei Chen explains why GitLab CI/CD Components (introduced in GitLab 16.x) is superior to the older include: template approach for reusing CI/CD jobs. Three key benefits: standardized input specification via spec:, better versioning through the CI/CD Catalog, and improved discoverability. The old approach forced awkward variable naming conventions (prefixed with XXX_) to avoid namespace collisions.
Cheng Wei Chen 解說 GitLab CI/CD Components 相比舊的 include: 模板方法的三大優勢：透過 spec: 標準化輸入規格、透過 CI/CD Catalog 更好的版本控制，以及更好的可發現性。舊方法需要用前綴命名（XXX_VAR1）來避免變數命名衝突的問題。
Key Points
- Old approach:
include:withvariables:requires prefix naming conventions to prevent collisions between different CI templates - CI/CD Components introduce
spec:block for declaring typed, validated inputs with defaults - Components are versioned and published to the CI/CD Catalog — enabling discovery and controlled version pinning
- Components enable semantic versioning (
@1.0.0) vs. arbitrary branch/tag references - Breaking change detection: the Catalog can flag when a new version breaks consuming pipelines
Insights
The input specification problem is fundamental to any template/plugin system: how do you pass parameters without namespace pollution? GitLab’s solution (a dedicated spec: block with typed, documented inputs) is cleaner than the environment variable approach and mirrors what other ecosystems solved (npm package.json, Helm chart values.yaml). The Catalog discovery angle addresses a real organizational problem: teams often rewrite CI logic that already exists elsewhere in the company because there’s no searchable registry.
Connections
Raw Excerpt
在 GitLab CI/CD Components 的時代，輸入 input 的問題，直接透過 spec: 的標準規範解決了。