Question
CircleCI 2.1: Should YAML Linting Be Looser for Dynamic Configuration?
Rey Orbit
0 reputation · 28 Feb 2020, 04:43 UTC
43.3K views1
Loading…
0 reputation · 28 Feb 2020, 04:43 UTC
When migrating to CircleCI 2.1, teams often employ dynamic configuration to generate parts of the pipeline at runtime. The validator, however, treats the entire .circleci/config.yml as static, flagging errors that only surface after the dynamic block is rendered.
The core goal is to determine whether the linting process should differentiate between static and dynamic sections, allowing the latter to bypass certain strict checks until execution time. This would reduce false positives for legitimate dynamic constructs while preserving safety for the static portion.
Key uncertainties include how to identify dynamic blocks in the YAML tree, whether a new lint rule could be scoped to those blocks, and if runtime validation would be sufficient to catch misconfigurations that static linting currently prevents.
1. Should the CircleCI validator defer linting of dynamic blocks until they are rendered at runtime?
2. Is there a mechanism to annotate dynamic sections so that specific lint rules are selectively applied?
3. Could a new lint rule be introduced that flags only static configuration errors, leaving dynamic sections unchecked until execution?
No. Do not loosen or defer YAML linting for dynamic configuration blocks in CircleCI 2.1. The validator does not provide a standard way to annotate part of .circleci/config.yml as dynamic, and it does not support selectively disabling lint rules for specific sections. Lint the authored file statically, and validate any generated or continued config separately after it is rendered.
circleci config process parses the authored config.yml, resolves orbs and parameters, and returns a nonzero exit code for schema or orb-reference errors. It does not execute setup jobs, so it cannot validate configuration that does not yet exist. A generated config produced by a setup job is enforced when CircleCI loads it at pipeline runtime, not during static linting.
circlecicircleci config process .circleci/config.yml locally and in CI on every change to the authored file.setup: true, generate the continued config inside the setup job, then run circleci config process on that generated file before the pipeline continues..circleci/config.yml; CircleCI may reject unknown keys during validation.Confirm whether your dynamic configuration uses CircleCI setup workflows with setup: true or an external pre-processor or orb. That determines where to insert generated-config validation and whether circleci config process can be run on the generated file in your environment.
config.yml and confirm circleci config process fails before any pipeline run.Assumption: this guidance assumes CircleCI 2.1 with the CircleCI CLI available. Version-specific behavior is unverified here and should be reviewed before rollout.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 28 Feb 2020, 08:45 UTC
One clarification: CircleCI 2.1 dynamic configuration is not a loose section inside the root config.yml that the validator can skip. The root file is fully static; it defines a setup job that generates a separate YAML payload and calls attach-config. The validator parses only that entry-point file and cannot see the generated output.
Because the dynamic config is a distinct artifact, block-level lint suppression would not apply. The practical boundary is between the static root and the runtime-attached payload. A useful follow-up is to run circleci config validate against the generated file inside the setup job before attaching it.