I’m currently exploring how CI/CD components can address some testing challenges I’ve encountered while working with CI templates. I’m particularly interested in hearing how others have tackled similar issues:
When it comes to whether jobs should be triggered for merge requests (MRs) versus branch pipelines, how do you manage this within your components? Do you typically handle this through specific rules embedded within the component itself, use input parameters, or implement conditional if rules at the template level that integrates the component?
What strategies do you use to test rules effectively? In cases where a template integrates multiple components, each potentially governed by its own set of conditional if rules, how do you ensure comprehensive testing? Starting with tests within the .gitlab-ci.yml seems straightforward, but what approaches do you follow to cover all conditions outlined in the rules?
I’m using the OpenTofu CI/CD component as an example here. Just briefly: it consists of a bunch of templates and an associated Container Image that includes a custom wrapper script shell script around tofu.
As a rule of thumb I try to put most of the heavy lifting the component does into the shell script which I can “unit test”.
The harder part is testing the templates (which you asked for). What I do here is that in my components .gitlab-ci.yml I have an integration-test stage with a bunch of jobs each representing a single integration test. An integration test just triggers a child-pipeline with a pipeline configuration that “simulates” the usage of the templates using “test inputs” - the integration test passes if that child-pipeline passes.
(the blue box shows the integration test job and the red box the child-pipeline it triggered)
This approach works pretty well to test certain input combinations. I’m also not directly triggering a child-pipeline but have an “intermediary” pipeline configuration that can augment the template job for testing purposes. Here are some implementation references:
Because of the precedence of variables you can overwrite the most important variables in your “intermediary” pipeline definition - which includes the predefined CI/CD variables. However, be careful with that!
