Skip to content

3. Initialize the SFDX project

Initialize the SFDX project

  • Create a new git branch named cicd under your lowest major branch (usually integration)
  • Run the command Configuration -> Create new sfdx project (sf hardis:project:create) and select the options to create a new sfdx-hardis project

Use the sfdx-hardis command to create the new project, not the default Salesforce one.

  • Open the file manifest/package.xml and replace its content with the following code
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<version>65.0</version> <!-- use the current Salesforce API version -->
</Package>
  • If you use GitLab CI and sandboxes only (no scratch orgs), open gitlab-ci-config.yml at the root of the repository and set the variable USE_SCRATCH_ORGS to "false"
  • With GitHub, Azure, Bitbucket or Jenkins, the scratch org jobs (create a scratch org or take one from the scratch org pool, run the Apex tests on it, delete it) are off by default: set the variable USE_SCRATCH_ORGS to "true" to run them. To keep scratch orgs ready in a pool, see Set up a scratch org pool.

  • Depending on your Git provider, keep the related workflow files and delete the others

    • GitLab
      • gitlab-ci.yml
      • gitlab-ci-config.yml
    • Azure
      • azure-pipelines-checks.yml
      • azure-pipelines-deployment.yml
      • azure-pipelines-scratch-pool.yml (only if you use a scratch org pool)
      • azure-pipelines-major-branch-check.yml (only if you use the major branch deployment check)
    • GitHub
      • Folder .github/workflows
    • Bitbucket
      • bitbucket-pipelines.yml
  • During the CI/CD setup, find the variable SFDX_DISABLE_FLOW_DIFF in the pipeline of your Git provider and set its value to true, to avoid generating too many Pull Request comments during the setup. At the end of the setup, set the variable back to false.

Some workflow files contain additional configuration instructions: read the comments at the beginning of the files.

Upgrade the CI/CD files

The CI/CD files are copied once, when the project is created: a new version of sfdx-hardis does not update them. Each one starts with the URL of the sfdx-hardis template it comes from, for example:

# Source of this file: the sfdx-hardis default template
#   https://github.com/hardisgroupcom/sfdx-hardis/blob/main/defaults/ci/.gitlab-ci.yml

To upgrade a file, by hand or with a coding agent, compare it with the latest version of its template and bring in the changes, keeping what is specific to your project: branch names, secrets, runner tags, image, custom jobs. .gitlab-ci-config.yml holds the values of your project: only add its new keys. The changelog says what changed between versions.

You can now go to step 4. Configure CI authentication.

Comments