Trigger CI Pipeline

With your infrastructure as code, and tests along with your pipeline file present in your Git repo config change branch, the next step you need to take is to create a merge request. Merge request is the terminology used by GitLab and is equivalent to GitHub's Pull Request terminology. This is the step in the process where the developer opens a "ticket" for the change to the code base, i.e. main branch, they wish to make. Upon opening this ticket request, Continuous Integration (CI) occurs where the build and test steps execute. In the paradigm of NetDevOps with CI, the build and deploy phase is the configuration of the test network and the testing is the linting steps and pre-/post- network test steps.

Step 1 - Create a Merge Request

From your GitLab project page:

1. Click Create merge request

Step 2 - Open Merge Request

In the Merge Request perform the following:

1. Insert a description: Test network configuration change to add OSPF and BGP to C8Kv-01, BGP neighbor to C8Kv-01 on CSR1Kv-01 & N9Kv-01, and OSPF enabled on XR9Kv-01 interface connecting to C8Kv-01.
2. Click Create merge request

Step 3 - Navigate to Pipeline

Navigate to the pipeline that was launched when you opened your Merge Request:

1. Click the number for the merge request pipeline that comes after Merge request pipeline

Step 4 - Review Overall Pipeline

Review the graphical representation of your overall pipeine that you defined in your .gitlab-ci.yml file:

1. The linting stage will not take long to run the three steps: yamling, flake8, and ansible-syntax-check

Step 5 - Navigate to baseline-pre-tests step under pre-tests stage

After all the steps in your lint stage have completed, your pre-tests stage will start.

1. Click on baseline-pre-tests when you see it start

Step 6 - Review Running baseline-pre-tests Job

This will bring you to the job running your baseline-pre-tests that is using your CXTM API script to drive the execution of your first batch you created earlier in the lab within CXTM. The test cases in the batch are expected to pass, thus the pipeline step stage will pass, however, if one of the batch test cases fails, then the pipeline would fail.

1. When baseline-pre-tests completes, click the pipeline number on the right-side pane

Step 7 - Navigate to deploy-config-changes step under config-changes stage

After the completion of your pre-tests stage:

1. Click on deploy-config-changes when you see it start

Step 8 - Review Running deploy-config-changes Job

Review the running configuration changes job that is using your IaC Ansible playbook to modify the test network configuration. The playbook is expected to pass, but any failures would also result in the pipeline failing.

1. When deploy-config-changes completes, click the pipeline number on the right-side pane

Step 9 - Navigate to baseline-post-tests step under post-tests stage

After the config-changes stage has completed, your post-tests stage will start.

1. Click on baseline-post-tests when you see it start

Step 10 - Review Running baseline-post-tests Job

This will bring you to the job running your baseline-post-tests that is using your CXTM API script to drive the same execution of your first batch you ran in the pre-tests stage. The test cases in the batch are expected to pass, thus the pipeline step stage will pass, however, if one of the batch test cases fails, then the pipeline would fail.

1. When baseline-post-tests completes, click the pipeline number on the right-side pane

Step 11 - Navigate to routing-post-tests step under post-tests stage

After the baseline-post-tests step has completed, your routing-post-tests step will start in your post-tests stage.

1. Click on routing-post-tests when you see it start

Step 12 - Review Running routing-post-tests Job

This will bring you to the job running your routing-post-tests that is using your reusable CXTM API script to drive the second batch you created in CXTM focused on routing tests. The test cases in the batch are expected to pass, thus the pipeline step stage will pass, however, if one of the batch test cases fails, then the pipeline would fail.

1. When routing-post-tests completes, click the pipeline number on the right-side pane

Step 13 - Return to GitLab & Review Repo

Congrats! You successfully ran your CI pipeline for your proposed configuration change and all the tests you developed passed! This configuration change is ready for your next maintenance window.

Step 14 - Navigate to your CXTM Project's Batches page

Step 15 - Review the Verify BGP Neighbor State on IOS-XE via CLI test case

From your project's Batches page:

1. Click on the Results link for the LTROPS-2711 Topology Routing Batch




2. Click on the Details link associated with the Verify BGP Neighbor State on IOS-XE via CLI test case
3. Click on the on log.html link under Artifacts to open the Jobfile log



This link opens a detailed log.html report ("Jobfile Log") for all the procedures executed in the Job File.




4. Click on TEST 2. VERIFY ALL CONFIGURED BGP NEIGHBOR STATES ESTABLISHED FOR THE GIVEN DUT to expand
5. Click on FOR ${DEVICE} IN [ @{DEVICES} ] to expand
6. Click on ITERATION ${DEVICE} = CSR1Kv-01 to expand
7. Click on FOR ${neighbor} IN [ @{neighbors} ] to expand
8. Click on ITERATION ${DEVICE} = C8Kv-01 to expand
9. Click on FOR ${neighbor} IN [ @{neighbors} ] to expand





Compare this expanded output to the output you reviewed earlier after first runnng this test case in a batch. In this expanded output, notice that this test case has now iterated over both the CSR1Kv-01 and C8Kv-01 devices since you added C8Kv-01 to the DEVICES list earlier in the lab. Also, notice, now that the proposed configurations hae been pushed in the pipeline, that CSR1Kv device now has two BGP peers. It's now peered to 2.2.2.2 (the newly configured C8Kv-01), in addition to the peering to 4.4.4.4 (your N9Kv device) that was seen before.

Also notice that the C8Kv device has two BGP peers. One to 1.1.1.1 (the CSR1Kv device) and one to 4.4.4.4 (your N9Kv device).



10. Close the Jobfile log and return to the Job File Results page

Continue to the next section to review CXTM reporting now that your pipeline has run successfully.