The DevOps Toolkit: Working with Jenkins X/

...

/

Extending Build Pack Pipelines

Extending Build Pack Pipelines

This lesson explains how we can extend the build pack pipelines to run tests.

We'll cover the following...

We already saw that pipelines based on the new format have a single line: buildPack: go. To be more precise, those that are created based on a build pack are like that. While you can certainly create a pipeline from scratch, most use cases benefit from having a good base inherited from a build pack. For some, the base will be everything they need, but for others, it will not. There is a high probability that you will need to extend those pipelines by adding your own steps or even replacing a whole lifecycle (e.g., promote). Our next mission is to figure out how to accomplish that. We’ll explore how to extend pipelines used with serverless Jenkins X.

Creating a new branch

As any good developer would (excluding those who work directly with the master branch), we’ll start by creating a new branch.

Press + to interact
git checkout -b extension

Increasing the value of replicaCount in values.yaml

Since we need to make a change to demonstrate how pipelines work, instead of making a minor modification like adding a random text to the README.md file, we’ll do something we should have done a long time ago. We’ll increase the number of replicas for our application. We’ll ignore the fact that we should probably create a HorizontalPodAutoscaler and simply increase the replicaCount value in values.yaml from 1 to 3.

Given that I want to make it easy for you, we’ll execute a command that will make a change instead of asking you to open the value.yaml file in your favorite editor and update it manually.

Press + to interact
cat charts/go-demo-6/values.yaml \
    | sed -e \
    's@replicaCount: 1@replicaCount: 3@g' \
    | tee charts/go-demo-6/values.yaml

Removing http:// from the tests

We’ll need to make another set of changes. The reason will become apparent later. For now, please note that the tests have a hard-coded http:// followed with a variable that is used to specify the IP or the domain. As you’ll see soon, we’ll fetch a fully qualified address so we’ll need to remove http:// from the tests.

Press + to interact
cat functional_test.go \
    | sed -e \
    's@fmt.Sprintf("http://@fmt.Sprintf("@g' \
    | tee functional_test.go
cat production_test.go \
    | sed -e \
    's@fmt.Sprintf("http://@fmt.Sprintf("@g' \
    | tee production_test.go

Now that we fixed the problem with the tests and increased the number of replicas (even though that was not necessary for the examples we’ll run), we can proceed and start extending our out-of-the-box pipeline.

Running unit tests

As it is now, the pipeline inherited from the build pack does not contain validations. It does almost everything else we need it to do except to run tests. We’ll start with unit tests.

Where should we add unit tests? We need to choose the pipeline, the ...

Access this course and 1400+ top-rated courses and projects.