sfops - On Push to Branch

The below sections details the workflow that get triggered on a push to the main and release/* branches

name: 'sfops - On Push to Branch'


on:
  push:
    branches:
      - 'main'
      - 'release/**'

  workflow_dispatch:



#Set the environment variables for tracking metrics
env:
  SFPOWERSCRIPTS_DATADOG: 'true'
  SFPOWERSCRIPTS_DATADOG_HOST: '${{ secrets.DATADOG_HOST }}'
  SFPOWERSCRIPTS_DATADOG_API_KEY: '${{ secrets.DATADOG_API_KEY }}'


jobs:
   build-test-publish:
    name: 'Build & Publish'
    uses:   flxbl-io/sfops-gh-actions/.github/workflows/push-to-branch.yml@main
    with:
       releaseconfig: 'config'
       branchname: ${{ github.ref_name }}
       pathToReleaseConfigs: 'config'
       dashboard-repo: ${{ vars.SFOPS_DASBHOARD_REPO }}
       releasename: ${{ vars.RELEASENAME }}
       metrics-provider:  ${{ vars.SFOPS_METRICS_PROVIDER }}
       workitem-url: ${{ vars.SFOPS_ISSUETRACKER_URL }}
       workitem-filter:  ${{ vars.SFOPS_ISSUETRACKER_WORKITEM_FILTER }}
       sfopsbot-app-id: ${{ vars.SFOPSBOT_APP_ID }}
    secrets:
      DEVHUB_SFDX_AUTH_URL: ${{ secrets.DEVHUB_SFDX_AUTH_URL }}
      SB_SFDX_AUTH_URL: ${{ secrets.SB_SFDX_AUTH_URL }}
      DATADOG_API_KEY: ${{ secrets.DATADOG_API_KEY }}
      DATADOG_HOST: ${{ secrets.DATADOG_HOST }}
      SFOPSBOT_APP_PRIVATE_KEY: ${{ secrets.SFOPSBOT_APP_PRIVATE_KEY }}
      NPM_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Within an individual build-deploy-publish cycle, the following happens in sequence

1. Impacted packages are detected and queued for build

2. Upon successful completion of the build, the packages that are created are deployed in parallel to a dynamic list of deployment targets. These deployment targets form your test environments

3. If all the deployment targets succeeded, the packages are published and a release candidate is created for the corresponding domain

There could be 0..N deployment targets, and these deployment targets are marked by the filter "type:test, branch:<current_branch>", If no deployment targets , the process is skipped and moved to publish. The deployment targets could be dynamic or static

One then could determine, after further testing whether the created release candidate can be promoted to production or rejected. As you must have noticed, these tests are more quality gates. Tests such as User Acceptance Testing should be carried out before the work item is merged to the branch. If any bugs are discovered at this stage, these should be fixed in priority or the feature should be toggled off or excluded from release candidate for further promotion