Manual Pipeline¶

Once you've written and committed the .gitlab-ci.yml file, a pipeline won't automatically run. This is because of the rules: we applied to the stages in our pipeline: only changes to *.tf files will trigger the pipeline. So how do we over come this?

Manual Trigger¶

To get GitLab to execute our pipeline for us we have to trigger it in the GitLab UI. When we traverse to the the CI/CD Pipeline section on the left hand menu (CI/CD -> Pipelines) you'll see something along these lines:

To get a pipeline to run we'll have to do one of two things:

1. Change some Terraform code, but we have no changes to make, or
2. Manually trigger the pipeline

Let's go with option 2 and click the "Run pipeline" button in the top right of the page.

Pipeline Details¶

After you've executed the pipeline you'll see this:

On this page we're able to set up some context and variables for our pipeline before it executes:

1. We can change the branch the pipeline will run against
2. We can define environment variables that will be passed into the pipeline during execution

At this point in time we don't really need to change anything, but in the future there might be a need to run a pipeline against a specific tag to perform a roll back, for example. Supplying variables to a pipeline can be a good way of telling your scripts what they're meant to do or what decisions to make based on the values.

For now we'll simply ignore these options, as the defaults are fine for our needs, and click "Run pipeline". You'll see this, next:

We're presented with a bit of information here. From left to right:

• The "Running" means the current status of the pipeline
• We have the pipeline ID (which can be clicked)
• The user who executed the pipeline (directly or indirectly)
• The branch and commit the pipeline is operating on
• A small visual aide that helps us see what stage the pipeline is currently running
• And the "In progress" which means the pipeline is running

After the pipeline has finished running the final piece of information, what we see above as "In progress", will change to two pieces of information: the amount of time the pipeline took to execute and when it was executed.

Viewing the Stages¶

If we click on the pipeline ID (in the screenshot that's the number 345276206), we see this:

We're getting a lot of the same information here that's being rearranged, but also some new information:

1. The number of jobs: three in this case, for the master branch
2. The latest tag which just means this is the latest pipeline for the given project
3. Information about the commit this pipeline relates to
4. And Merge Request information, which is nothing here because this isn't a Merge Request

Below this we get to see a visual breakdown of the pipeline itself and the stages being executed. In our case we see three stages: validate, plan and apply. We don't see the destroy stage because we didn't create the .destroy file, so that stage is skipped.

Clicking on a stage will go further into the pipeline, focusing on that stage, and will render the logs from any scripts that stage is running. Here's an example of what the planning stage looks like when it's finished:

Review the Plan¶

With the plan complete, you should review it in detail to ensure it's what you expected. If it's not, I recommend deleting the pipeline and going back to the code, review it, change it, push it and start again.

Deleting a pipeline seems like overkill, but consider this: what if someone runs the apply stage two weeks down the line from today? I cannot answer that question nor tell you how much chaos will ensue, but it's better to be safe than sorry and simply delete the pipeline.

To do this, go to the pipeline view (the one with the stages) and in the top right there is a button, "Delete" - click it. Now no one can run this pipeline in the future and potentially break things.

Next¶

The next section will discuss triggering a terraform apply so that we can build our infrastructure.