Building CI/CD process for my new Salesforce AppExchange utility package (2GP) using CumulusCI and GithubActions

Here are my requirements for the CI/CD process:

• Work will be done in VS Code in feature branches based off of main branch
• Approved pull requests or merges to main will trigger the deployment of a new beta package after the namespace is injected.

Ok to be honest… I already have this one working. It is a thing of beauty. I’ll actually build the boiler plate for my next app (sentfolder) from the ground up… I promise.

Lets take a look at the folder structure and files inside the utility app to see what makes it work.

• The first step was to setup my boiler plate code space for CCI and SFDX, and push that into my github repo.
• Next, I followed these instructions: https://cumulusci.readthedocs.io/en/latest/github-actions.html and then specifically cloning the reusable workflows at https://github.com/cumulus-actions/standard-workflows and moving them into my .github/workflow file.
• Then I created my own build file based upon their examples but I replaced their repo with my own copy of the reusable workflows. I will have to keep an eye on these for the future in case of upgraded functionality.

main_upload_beta.yml

• This build file will trigger a github action for every commit to main. This is the same for me as my local CCI process of:

cci flow run release_2gp_beta --org dev

• Next I created a repository secret for my dev hub auth url. This is found from the cli by running:

sfdx force:org:display --json --verbose -o cp-biz # where cp-biz is my devhub

And pasting the resulting value from the sfdxAuthUrl into the Github repo secret DEV_HUB_AUTH_URL

Note… I tested repository secrets AND environment secrets and at the present time it appears as though reusable github action workflows do not support environment variables beyond the calling script (meaning I will have to pass the secret through all of the scripts manually as a parameter… I have entered a backlog item)

— The first time the job runs, it will actually create you a package version so be careful running this command against your namespace.

— All subsequent pushes to main trigger a new beta package release. Amazing! I just fired a release engineer who was no longer necessary. Whoops.

So much more to see here… as we build out the app I will be adding the support for environment provisioning, namespace management, automated testing, and all sorts of cool stuff.

Stay tuned! I will update this guide when i build out more!