Create GitLab CI File to Define Pipeline

To continue moving toward implementing a CI pipeline. You will now create the file required by GitLab to configure the pipeline.

Step 1 - Create a New YAML File in Visual Studio Code For GitLab CI File

In your VS Code Terminal, use the code-server keyword to open a YAML file called .gitlab-ci.yml.

GitLab looks for this particular hidden file in a repo to leverage its CI/CD pipeline feature.

code-server -r /home/user21/ciscolive/LTROPS-2711/.gitlab-ci.yml

Step 2 - Populate GitLab CI YAML File

This hidden file defines the pipeline and the stages to run. Your pipeline for this lab will have four stages defined: lint, pre-tests, deploy, and post-tests.

• lint stage: The lint stage will be used to check that your infrastructure as code files are syntactically correct and valid for execution and runtime. For linting, you will leverage yamllint to check your repo for correct YAML formatting, and ansible-playbook --syntax-check to validate the syntax and structure of your previously created playbooks.
• pre-tests stage: This stage is defined to run your baseline tests, i.e. your first batch in CXTM before the configuration change is deployed to your test network. This stage will leverage the cxtm-mgr websocket feature to communicate with CXTM to run your test cases and receive real time test execution status updates.
• deploy stage: The deploy stage is for deploying to your IaC configuration change to your test network via the Ansible playbook.
• post-tests stage: This stage is defined identically as the pre-tests stage, but adds an additional step to run your second routing batch of test cases post-configuration change to your test network. This stage will also leverage the cxtm-mgr websocket feature to to run the test cases and receive real time test execution status updates.

As you populate and review the pipeline below, make note of the only and except keys. These dictate which stages are run against which branch or not run against a branch. As done in this lab, typically it is the main branch that is used with these keys. For example, when you want the pipeline to run against your staging setup, then you will notice that except is used so that a particular step is not run on main. On the contrary there are steps only applicable for prod, thus the only key is used to specify main.

The last two pieces to this pipeline is the usage of the only key to also control when the pipeline is run. For example, you could have the pipeline run against staging every single time a commit is pushed to the repo. Depending on your devops process, that may be required, but for this lab, only will be used to control the pipeline running when a merge request is created. A merge request will be expanded on in the next section, but in short, this is the process of merging your code from another branch, such as your staging branch in this case, into main. The other piece is the script key that defines a list of the commands to execute to run your automation. In this case, you will be using the cxtm-mgr client to instruct CXTM to run the system and routing batches that you created earlier in the lab.

Step 3 - Copy and paste the GitLab CI file into your open .gitlab-ci.yml file in VS Code:

1. Copy and paste the GitLab CI file into your open .gitlab-ci.yml file in VS Code:

---
image: cait:25.2

variables:
  ANSIBLE_HOST_KEY_CHECKING: 'false'
  ANSIBLE_FORCE_COLOR: 'true'
  ANSIBLE_PERSISTENT_COMMAND_TIMEOUT: 100
  ANSIBLE_PERSISTENT_CONNECT_TIMEOUT: 100
  CXTM:
    description: "Cisco CXTM IP or FQDN"
  TM2_API_KEY:
    description: "Cisco CXTM API Key"

stages:
  - lint
  - pre-tests
  - deploy
  - post-tests

yamllint:
  except:
    - main
  only:
    - merge_requests
  stage: lint
  script:
    - echo "Checking YAML files"
    - yamllint -d relaxed .

ansible-syntax-check:
  except:
    - main
  only:
    - merge_requests
  stage: lint
  script:
    - echo "Checking Ansible playbook"
    - ansible-playbook --syntax-check -i ansible/hosts.yml ansible/playbook.yml

baseline-pre-tests:
  except:
    - main
  only:
    - merge_requests
  stage: pre-tests
  script:
    - echo "Tests before config changes"
    - cxtm-mgr batch --host $CXTM --insecure run --output tests/cxtm.log.xml <Batch ID 1>
  artifacts:
    paths:
      - tests/cxtm.log.xml
    reports:
      junit:
        - tests/cxtm.log.xml

deploy:
  except:
    - main
  only:
    - merge_requests
  stage: deploy
  script:
    - echo "Deploy config changes to test network"
    - ansible-playbook -i ansible/hosts.yml ansible/playbook.yml

post-tests:
  except:
    - main
  only:
    - merge_requests
  stage: post-tests
  script:
    - echo "Tests after config changes"
    - cxtm-mgr batch --host $CXTM --insecure run --output tests/cxtm.log.xml <Batch ID 1> <Batch ID 2>
  artifacts:
    paths:
      - tests/cxtm.log.xml
    reports:
      junit:
        - tests/cxtm.log.xml

In your .gitlab-ci.yml file in VS Code:

2. Replace <Batch ID 1> with the LTROPS-2711 Topology System Batch ID noted down from the Create Test Case Batches section. Make sure that Batch ID 1 is replaced in both the pre-tests stage on line 48 and in the post-tests stage on line 74 of your .gitlab-ci.yml file.
3. Replace <Batch ID 2> with the LTROPS-2711 Routing System Batch ID noted down from the Create Test Case Batches section. Make sure that Batch ID 2 is replaced in the post-tests stage on line 74 of your .gitlab-ci.yml file.
4. After successfully populating .gitlab-ci.yml with the above connection information, save your .gitlab-ci.yml file using Ctrl+s on the Windows keyboard or by clicking File then Save.

Step 4 - Add Files for Committing to Repo

After initializing your Git repo and creating the files specific to your prod fabric, it is time to add these files with Git in preparation for committing them to the repo. You perform the action of adding files with git add. You will add your .gitlab-ci.yml file and add your ansible directory.

git add .gitlab-ci.yml
git add ansible/*

Step 5 - Commit Files to Git Repo

With your directories and files added, you can now commit them to your Git repo with git commit. The -m option is for a comment/message for the commit.

git commit -m "Initial config change testing commit"

Step 6 - Push Files to Git Repo

Finally, with your project directory initialized as a Git repo, your files added and committed, you can push everything to your Git repo on the GitLab instance.

git push -u origin config-changes-testing

Step 7 - Return to GitLab & Review Repo

1. Return to GitLab repo by clicking on the LTROPS-2711 project name on the left side menu.

Continue to the next section to trigger the pipeline and review the results.