Before creating a CI job, you first need to have added some connections to your orgs or source control repositories. You can add orgs from these from the `My connections` tab.
If you are building your first CI job, and you are a team owner, you'll be confronted by this page, where you can choose if you want to create a team-shared CI job or a user-owned CI job.
Please note that if you are a team member you'll only be able to create a user-owned CI job.
In this guide you'll find the two most common use cases for CI jobs are:
Git to Org CI job
Navigate to the Continuous integration page, found under Automation in the nav menu on the left.
Click on Add new deployment job....
This will take you into the CI job creation wizard.
Job Name - Give the job a descriptive name.
Source type - Select your Git provider, Repository and branch as required.
Decide whether to filter the comparison by package.xml.
Select the target org as required.
Select either Deployment or Validation action.
Validation-only CI jobs - This will run a validation of the package against the chosen org. Then you are able to deploy the package at a later date.
Select either Delta CI or if you would like to run a full sync between source and target.
Choose how often you want the job to run. Either select when the branch is updated (recommended), or select a time interval.
Note: If you choose 24 hours as the runtime, the first automated run will be sometime in the next 4-hour period. The job will then be scheduled to run between midnight and 4 am UTC.
Select if you would like to validate PRs against the source branch.
Any PRs that you open against the source branch will then be validated against the org, so that you know that you are able to merge and deploy.
Next you also have an option to send a notification each time a pull request is validated. The notification is sent based on your set-up for your notification settings (via email, slack, chatter, etc.)
Select if you would like the job to include New items, Changed items, and Deleted items.
Decide if you want to include changes to user permissions in your CI job; by default, these are excluded.
Specify the unit test level you would like for the CI job.
On the Metadata filter tab, set the metadata filter you'd like the job to use. This defines which metadata types the CI job will compare and deploy between your source and target.
Specify any Deployment gates that you wish to include. In CI jobs this is done by selecting a Static code analysis ruleset if the CI job fails on those rules then the job will not validate.
You can set an outgoing webhook as part of continuous integration jobs in Gearset.
Here you can select the Problem Analyzer templates that are used in each run, or you can choose to not apply any fixes to skip problem analysis.
Choose whether to get notified after every CI job run, irrespective of the outcome, or only if the CI job fails.
Click Save to create the job.
Note: If you selected delta CI an empty run will trigger, this will set a baseline for future commits.
The next box will prompt you to add a webhook.
Clicking Add Webhook will automatically create the webhook in your VCS, with all the correct permissions attached.
Note: If there is already a usable webhook set up in your repo, we'll add this job to the pool that webhook serves, and you won't need to add another.
Org to Org CI job
Navigate to the Continuous integration page, found under Automation in the nav menu on the left.
Click on Add new deployment job....
Job Name - Give the job a descriptive name.
Source type - Select Salesforce, and the source org.
Select the target org as required.
Select either Deployment or Validation action.
Validation-only CI jobs
This will run a validation of the package against the chosen org. Then you are able to deploy the package at a later date.
Choose how often you want the job to run.
Note: If you choose 24 hours as the runtime, the first automated run will be sometime in the next 4-hour period. The job will then be scheduled to run between midnight and 4 am UTC
Select if you would like the job to include New items, Changed items, and Deleted items.
Decide if you want to include changes to user permissions in your CI job; by default, these are excluded.
Go to the next step.
Specify the test level you would like for the CI job. If you select the option to "Choose which tests to run" you'll have more options to:
Go to the next step.
On the Metadata filter tab, set the metadata filter you'd like the job to use. This defines which metadata types the CI job will compare and deploy between your two orgs.
Select the level of Static code analysis that you would like and if you would like validations to fail if those SCA issues are detected.
You can set an outgoing webhook as part of continuous integration jobs in Gearset.
Here you can select the Problem Analyzer templates or you can choose to not apply any fixes to skip problem analysis.
Choose whether to get notified after every CI job run, irrespective of the outcome, or only if the CI job fails.
Click Save to create the job.
How are CI jobs used in Pipelines? Watch our short demo video.
Based on Gearset's powerful CI jobs, Pipelines brings some new functionality to help you manage where changes are in your release process, and helps give your entire team visibility and control over the workflow.