Dynamically generate CI/CD pipelines

WHAT THIS TESTS This advanced question probes platform-engineering judgment: can you build a convention-over-configuration pipeline system and honestly weigh the loss of explicitness against the gain in consistency.

A GOOD ANSWER COVERS Design it in two phases. A detection phase checks out the repository and scans for marker files: a pom.xml or build.gradle implies a JVM build, a Dockerfile implies a container build, a package.json implies a Node build and test, presence of test directories implies a test stage. Map each detected marker to a reusable, parameterized stage template stored centrally, so logic lives in one place. An assembly phase composes the selected templates, in a sensible order with dependencies, into a concrete pipeline that the runner executes, using a generated or programmatic pipeline definition. Many tools support this: Jenkins scripted pipelines, GitLab parent-child and dynamic child pipelines, GitHub Actions reusable workflows with matrix or conditional jobs.

TRADE-OFFS, which the question explicitly asks for: the upside is DRY, consistent, low-maintenance onboarding, new repos get a correct pipeline for free. The downside is reduced transparency, the effective pipeline is not visible by reading a checked-in file, which surprises developers and complicates debugging. Generated steps are harder to reproduce locally and to audit. There are security concerns: dynamically assembling and executing steps based on repo contents can be exploited if an attacker adds a marker or a malicious template, so templates must be trusted and versioned. Detection can produce false positives, a stray Dockerfile in a docs folder triggering an unwanted build.

COMMON WRONG ANSWERS Describing only the happy-path detection with no discussion of the transparency, debuggability, and security costs the question asks for. Hard-coding every case instead of a template registry. Ignoring ordering and dependencies between stages.

LIKELY FOLLOW-UPS How do you let a repo override or opt out of detection? How do you version and test the templates themselves? How do you prevent a malicious repo from injecting steps? How do you make the generated pipeline observable and reproducible?

ONE CONCRETE EXAMPLE A detection job clones the repo, finds both a pom.xml and a Dockerfile, and emits a child pipeline with a Maven build-and-test stage followed by a container build-and-push stage. A second repo with only package.json gets a Node install, lint, test pipeline instead, all without either team writing pipeline YAML, at the cost that neither can read their full pipeline in their own repository.