This section has just scratched the surface of what is possible with Jenkins and Jenkinsfile. You can continue to extend your Jenkinsfile to perform additional stages, such as static code analysis and/or even custom DX CLI plugins to write statistics back to your own Salesforce production environment. You can read more about the commands and features of Jenkinsfile here: https://jenkins.io/doc/book/pipeline/syntax/.

Continue to explore this process a bit further by making changes to the repository to see how the Jenkins pipeline responds. Let's deliberately break some tests and commit the changes straight away! This, of course, would normally be bad practice, but the point of this is to see how pipelines defend the overall quality of the code base, even if mistakes happen:

1. Edit the ContestantsTest.testAddContestantNoneScheduled method Apex test as shown here:

Line 12: 
Race__c race = new Race__c(Name = 'Spa', Status__c = 'Scheduled', Season__c = season.Id);

2. Edit the raceSetup.test.js Lightning Web Components test as shown here:

Line 69:
const SELECTED_ROWS = 
    [
        {
            "RecordId": DRIVER2_ID,
            "Name": "Sergio Pérez",
            "Selected": true
        }
    ];

3. Use the Visual Studio Code source control integration (highlighted earlier in this chapter) to commit and publish your changes to the GitHub repository. Note that, normally, you would do this via a pull request; committing directly to the master branch is typically not good practice.
4. After a minute, you will see that the Jenkins pipeline has observed that a change has occurred and started a build. The following screenshot shows that the build has failed due to test failures:

If you revert the preceding changes and commit then push those changes, you will see that the build will recover and reward you with a nice sunshine icon! Next, let's see how to release from source control.