Salesforce app pipeline on GitHub Actions

I already examined how to automate some CI/CD tasks using GitLab (auth, testing and packaging). Good news — GitHub actions are available for everyone, so it’s time to run similar processes on GitHub as well! René already has written an introduction post on Salesforce Dev Blog; now I go a little bit more into details.

GitHub actions are a very simple thing: on different events (such as a push) some code is fired on a virtual machine which is hosted by GitHub. Most common use case of this kind of code is to automate continuous integration tasks.

Every repo has its own action definition file. For setting up it manually, click ‘Set up a workflow yourself’ after clicking ‘Actions’

It is a simple file, under .github/workflows/main.yml — you can also edit in your own machine and simply commit.

When you push your code, it automatically runs. Our sample workflow does the following things below:

(If something went wrong, you will get a red sign and an email instead of green checkmark).

• We authenticate with a Developer Hub
• We create a scratch org
• We push the salesforce app code into the scratch org
• We run all the tests
• We delete the scratch org

Here how it looks in the action definition file:

If you know SFDX, you recognise a lot of things here — the authentication, the source push, the test run and the org delete (if you are new to SFDX, please visit the 3 links which I mentioned in the first paragraph). Basically, every ‘run’ parameter sets the running code for the given step. Let’s look into the github-specific stuff!

Checkout the repo

In the first step you see a command: actions/checkout@v2

This gets the repo into your working environment, so later you can access the files of your salesforce project.

Download SFDX

If you look into the part ‘Install Salesfoce CLI’ you see that we downloading and installing SFDX. It is because github action environment is absolutely software agnostic; so you need to set up your own environment.

Authorise SFDX

In order to use all the SFDX features you need a Dev Hub org and you need to authorise in your working environment as a Dev Hub. That’s happening in the part ‘Auth with the Devhub’. In an other post I described the JWT auth flow, but here I use another technique. The command uses a token which is saved in a file. The problem is that you don’t want to save it in a repo or even worse, in a public repo! Because if this you save the token in an environment value secret, and dump it into a file when building the environment. So nobody can access it. That’s happening in the ‘Write the token into a file’ part.

How to get the token? You need to auth the Dev Hub on your own machine, and display the token using the force:org:display command. Here how you get the token url:

Delete the org

At the end of all your testing, add the delete line — otherwise you can hit scratch org limits if you commit to your repo too often.

This is just scratching the surface; you can do with GitHub actions almost anything. The great thing about them that their format is very similar to GitLab pipelines, so it’s easy to use the same techniques in both places.

Happy coding and please give me a clap if you liked the post ;)