Answers: <p>You should use CI lint.
  See this to simulate your CI/CD pipeline and validate when you make changes to the yml file - <a href="https://docs.gitlab.com/ee/ci/lint.html" rel="nofollow noreferrer">https://docs.gitlab.com/ee/ci/lint.html</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2022-03-25T10:45:15.230Z
Answers: I do not want to check syntax. I want to control that depending on the environment variables, the jobs are created correctly. in the lint tool I cannot specify environment variables (or secrets) when I check 'simulate a pipeline for the default branch' and as a result nothing runs.
Answers: John Doe
Answers: CC BY-SA 4.0
Answers: 2022-03-24T18:34:21.357Z
Answers: 2022-03-24T18:34:21.357Z
Answers: kaushikv
Answers: <p>This is where using Terraform or some other Infrastructure as Code tool can really help.  You could on a merge, create a test environment and then run through the various deployments to that environment.  If you have some sort of acceptance tests built-in, you can verify that the builds/deployments still work, and that the code still functions.  After the tests are done, you can teardown the test environment and proceed to deploy normally.</p>
  <p>Another option would be to build a pipeline that triggers these builds you need to test.  So when you change this root file -&gt; trigger one &quot;build&quot; that causes all of the dependent builds to fire.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-01-02T12:18:06.660Z
Answers: what i want to test is not the build output but that the build pipeline is itself created correctly. e.g. if this env var is set it should trigger this command, etc..
Answers: John Doe
Answers: CC BY-SA 4.0
Answers: 2022-12-19T18:00:12.363Z
Answers: 2022-12-19T18:00:12.363Z
Answers: Wesley Rolnick
Body: <p>I have gitlab CI/CD defined through <code>.gitlab-ci.yml</code>.</p>
  <p>It runs different jobs if the pipeline is triggered manually, from a merge request or from a scheduled pipeline.</p>
  <p>It accepts a bunch of environment variables used to modify some job behaviors or launch specific jobs (for example for developers to build debug images).</p>
  <p>When I change <code>.gitlab-ci.yml</code>  I currently have to run manual tests triggering the pipelines in all possible ways with all the different variables to ensure I have no regression.</p>
  <p>Do I have a way to automate that? Is there other CI/CD tools that allow that?</p>
  
Tags: <gitlab><testing>
Title: How to test the CI/CD pipeline itself?
UserDisplayName: John Doe
ThreadText: # How to test the CI/CD pipeline itself?
  
  (Asked by: username_0 on 2022-02-15)
  
  I have gitlab CI/CD defined through `.gitlab-ci.yml`.
  
  It runs different jobs if the pipeline is triggered manually, from a merge request or from a scheduled pipeline.
  
  It accepts a bunch of environment variables used to modify some job behaviors or launch specific jobs (for example for developers to build debug images).
  
  When I change `.gitlab-ci.yml` I currently have to run manual tests triggering the pipelines in all possible ways with all the different variables to ensure I have no regression.
  
  Do I have a way to automate that? Is there other CI/CD tools that allow that?
  
  **Tags:** gitlab, testing
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2022-03-24. Score: 1
  
  You should use CI lint.
  See this to simulate your CI/CD pipeline and validate when you make changes to the yml file - <https://docs.gitlab.com/ee/ci/lint.html>
  
  > **Comments:**
  > **username_0**: I do not want to check syntax. I want to control that depending on the environment variables, the jobs are created correctly. in the lint tool I cannot specify environment variables (or secrets) when I check 'simulate a pipeline for the default branch' and as a result nothing runs.  
  
  ---
  
  ### Answer by username_2 on 2022-12-19. Score: 0
  
  This is where using Terraform or some other Infrastructure as Code tool can really help. You could on a merge, create a test environment and then run through the various deployments to that environment. If you have some sort of acceptance tests built-in, you can verify that the builds/deployments still work, and that the code still functions. After the tests are done, you can teardown the test environment and proceed to deploy normally.
  
  Another option would be to build a pipeline that triggers these builds you need to test. So when you change this root file -> trigger one "build" that causes all of the dependent builds to fire.
  
  > **Comments:**
  > **username_0**: what i want to test is not the build output but that the build pipeline is itself created correctly. e.g. if this env var is set it should trigger this command, etc..  
  
  ---
  
  