Github Workflow for Package Development

To better maintain my OSS repositories I am looking for a simple but elegant Github workflow that covers all steps of a DX development process that ends with a package version (unlocked/managed):

  1. Scratch org creation and recreation for Feature development
  2. Run Test (Apex, Jest, PMD, etc) on org creation to check source integrity
  3. Pull Request handlers that do 1 and 2 to check the quality of a PR
  4. (Beta)Package Version creation on an approved PR
  5. Additional steps to create a Released Packaged

The usual suspects from Salesforce.com missed important requirements:

Answer

Disclosure: I am on the CumulusCI team at Salesforce.org.

This is CumulusCI’s raison d’etre. We’ve built CumulusCI for years to support building managed packages in GitHub. I completely understand your hesitation with using a tool built in a stack other than DX’s Node basis, but I’ll try to persuade you nonetheless.

CumulusCI works well in GitHub Actions. I recently presented a talk at SEA Dreamin (video forthcoming) about creating a CI/CD pipeline using Actions and CumulusCI. The example repo is here. It includes Actions workflows that:

  • perform feature tests;
  • upload beta package versions on merges to the main branch;
  • execute beta package tests;
  • execute Robot Framework browser automation and integration tests;
  • execute SFDX Scanner to run PMD;
  • execute Jest unit tests;
  • lint with ESLint;
  • validate formatting with Prettier.

As an example, here’s the complete workflow definition that uploads a beta package version:

name: Main Branch
on:
  workflow_run:
    workflows: ["Feature Test"]
    branches: [main]
    types:
      - completed
env:
  CUMULUSCI_SERVICE_github: ${{ secrets.CUMULUSCI_SERVICE_github }}
jobs:
  release_beta:
    name: "Upload Managed Beta"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install sfdx
        run: |
          mkdir sfdx
          wget -qO- https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz | tar xJ -C sfdx --strip-components 1
          ./sfdx/install
          echo ${{ secrets.SFDX_AUTH_URL }} > sfdx_auth
          sfdx force:auth:sfdxurl:store -f sfdx_auth -d
      - name: Set up Python
        uses: actions/setup-python@v1
        with:
          python-version: "3.9"
      - name: Determine Python Version
        id: python-version
        run: |
          echo "::set-output name=ver::$(python --version)"
      - uses: actions/cache@v2
        with:
          path: venv
          key: ${{ runner.os }}-${{ steps.python-version.outputs.ver }}-${{ hashFiles('requirements.txt') }}
      - name: Install CumulusCI
        run: |
          python3 -m venv venv
          venv/bin/pip install -r requirements.txt
      - run: |
          venv/bin/cci flow run release_2gp_beta --org feature

It’s fairly straightforward, and requires little over and above a base SFDX workflow, but automates the creation of a package version, plus the generation of a Release record in the GitHub repository and automatic generation of release notes from Pull Request content. (That’s all part of the fully-customizable release_2gp_beta flow).

With new features GitHub’s released in the last week or so, one of the steps (caching) should be able to be removed as it’s now built in to the OOTB actions.

We have documentation available that describes how to set up CumulusCI with GitHub Actions, as well as a Trail exploring the basics of the tool and how to create project-specific automation.

Attribution
Source : Link , Question Author : Robert Sösemann , Answer Author : David Reed

Leave a Comment