Jenkinsfile Walkthrough

Define Variables

Use the def keyword to define the variables required by the Salesforce DX CLI commands. Assign each variable the corresponding environment variable that you previously set in your Jenkins environment.

Define the SFDC_USERNAME variable, but don’t set its value. You do that later.

Although not required, we assume you’ve used the Jenkins Global Tool Configuration to create the toolbelt custom tool that points to the CLI installation directory. In your Jenkinsfile, use the tool command to set the value of the toolbelt variable to this custom tool.

You can now reference the Salesforce CLI executable in the Jenkinsfile using ${toolbelt}/sfdx.

Check Out the Source Code

Before testing your code, get the appropriate version or branch from your version control system (VCS) repository. In this example, we use the checkout scm Jenkins command. We assume that the Jenkins administrator has already configured the environment to access the correct VCS repository and check out the correct branch.

Wrap All Stages in a withCredentials Command

You previously stored the JWT private key file as a Jenkins Secret File using the Credentials interface. Therefore, you must use the withCredentials command in the body of the Jenkinsfile to access the secret file. The withCredentials command lets you name a credential entry, which is then extracted from the credential store and provided to the enclosed code through a variable. When using withCredentials, put all stages within its code block.

This example stores the credential ID for the JWT key file in the variable JWT_KEY_CRED_ID. You defined JWT_KEY_CRED_ID earlier and set it to its corresponding environment variable. The withCredentials command fetches the contents of the secret file from the credential store and places the contents in a temporary location. The location is stored in the variable jwt_key_file. You use the jwt_key_file variable with the force:auth:jwt command to specify the private key securely.

Authorize Your Dev Hub Org and Create a Scratch Org

The dreamhouse-sfdx example uses one stage to authorize the Dev Hub org and create a scratch org.

Use the force:auth:jwt:grant CLI command to authorize your Dev Hub org.

You are required to run this step only once, but we suggest you add it to your Jenkinsfile and authorize each time you run the Jenkins job. This way you’re always sure that the Jenkins job is not aborted due to lack of authorization. There is typically little harm in authorizing multiple times, although keep in mind that the API call limit for your scratch org’s edition still applies.

Use the parameters of the force:auth:jwt:grant command to provide information about the Dev Hub org that you are authorizing. The values for the --clientid, --username, and --instanceurl parameters are the CONNECTED_APP_CONSUMER_KEY, HUB_ORG, and SFDC_HOST environment variables you previously defined, respectively. The value of the --jwtkeyfile parameter is the jwt_key_file variable that you set in the previous section using the withCredentials command. The --setdefaultdevhubusername parameter specifies that this HUB_ORG is the default Dev Hub org for creating scratch orgs.

Use the force:org:create CLI command to create a scratch org. In the example, the CLI command uses the config/project-scratch-def.json file (relative to the project directory) to create the scratch org. The --json parameter specifies that the output be in JSON format. The --setdefaultusername parameter sets the new scratch org as the default.

The Groovy code that parses the JSON output of the force:org:create command extracts the username that was auto-generated as part of the org creation. This username, stored in the SFDC_USERNAME variable, is used with the CLI commands that push source, assign a permission set, and so on.

Push Source and Assign a Permission Set

Let’s populate your new scratch org with metadata. This example uses the force:source:push command to upload your source to the org. The source includes all the pieces that make up your Salesforce application: Apex classes and test classes, permission sets, layouts, triggers, custom objects, and so on.

Recall the SFDC_USERNAME variable that contains the auto-generated username that was output by the force:org:create command in an earlier stage. The code uses this variable as the argument to the --targetusername parameter to specify the username for the new scratch org.

The force:source:push command pushes all the Salesforce-related files that it finds in your project. Add a .forceignore file to your repository to list the files that you do not want pushed to the org.

After pushing the metadata, the example uses the force:user:permset:assign command to assign a permission set (named DreamHouse) to the SFDC_USERNAME user. The XML file that describes this permission set was uploaded to the org as part of the push.

Run Apex Tests

Now that your source code and test source have been pushed to the scratch org, run the force:apex:test:run command to run Apex tests.

You can specify various parameters to the force:apex:test:run CLI command. In the example:

• The --testlevel RunLocalTests option runs all tests in the scratch org, except tests that originate from installed managed packages. You can also specify RunSpecifiedTests to run only certain Apex tests or suites or RunAllTestsInOrg to run all tests in the org.
• The --outputdir option uses the RUN_ARTIFACT_DIR variable to specify the directory into which the test results are written. Test results are produced in JUnit and JSON formats.
• The --resultformat tap option specifies that the command output is in Test Anything Protocol (TAP) format. The test results that are written to a file are still in JUnit and JSON formats.
• The --targetusername option specifies the username for accessing the scratch org (the value in SFDC_USERNAME).

The force:apex:test:run command writes its test results in JUnit format. You can collect the results using industry-standard tools as shown in the following example.

Delete the Scratch Org

Salesforce reserves the right to delete a scratch org a specified number of days after it was created. You can also create a stage in your pipeline that uses force:org:delete to explicitly delete your scratch org when the tests complete. This cleanup ensures better management of your resources.