Comment on page
CI Jobs
Quick deployments are available when the following requirements are met.
- The components have been validated successfully for the target environment.
- As part of the validation, Apex tests in the target org have passed.
- Code coverage requirements are met.
- If all tests in the org or all local tests are run, overall code coverage is at least 75%, and Apex triggers have some coverage.
- If specific tests are run with the Run specified tests test level, each class and trigger that was deployed is covered by at least 75% individually.
If the baseline revisions aren't picking up the two revisions, clear the baseline revision and choose the same revision again.
You might have exceeded the maximum number of recipients; the maximum number of recipients should not exceed 50. Remove some of the recipients from the mail notification list and run the CI job again; you should now receive email notifications.
Build on Commit job: The user creates a CI job on one branch (For example, Integration). If any Commits are made on that branch on the remote, we will only perform the Pull (Delta changes), and then prepare the Package. This is why the build time is shorter.
Build on PR submission: CI job is created on the base branch (For example, Integration). If the developer works on the Feature 1 branch and creates the PR on the Integration branch, then the job gets triggered in ARM. The branch will switch to the Feature 1 branch, take the clone of the entire branch, prepare the changes between the two branches, and the switch back to master branch once the job is completed. This is why the build time is longer for PR jobs.
The authentication for your destination org may have expired. Please Re-authenticate your target Salesforce org. Once this is done successfully, please Edit and resave the CI job, then retrigger it.
This usually happens if the Ignore missing visibility checkbox is selected in CI Job. Another possibility is that the field in question is unavailable in the destination org where the FLS was deployed. Please contact our support team to determine the root cause and assist you further.
Based on the error, this may be due to the file size limit. We request you break down deployments into smaller chunks to be successful. Please refer to the Salesforce article below about the file size limits for deployments:
Salesforce Developers
Below are the types of CI jobs and their corresponding credential usage:
- 1.Forced/Manually Triggered Build: CI job process will consider the triggered User Credential which is mapped with the respective Repo and Branch in the My Profile section. If the credentials are invalid/expired, authentication fails and an error message is displayed upon build initiation. To resolve this issue, the user initiating the build must update the credentials in My Profile and perform a Test Connection. If it is successful, reinitate the CI job.
- 2.Build on Commit and Scheduled CI Job: CI job process will consider the last modifying user's credentials which is mapped with the respective Repo and Branch in the My Profile section. If the credentials are invalid/expired, the CI job build fails and authentication error message is displayed in the CI job Build log. To resolve this issue, the user who last modified the CI job must update the credentials in My Profile and perform a Test Connection. If it is successful, the job will be executed in the next cycle.
- 3.CI job build initiated from API: CI Job process will consider the Token user credential which is mapped with the respective Repo and Branch in the My Profile section. If the credentials are invalid/expired, the CI job build fails and authentication error message is displayed in the CI job Build log. To resolve this issue, user generating the token must update the credentials in My Profile and perform a Test Connection. If it is successful, the job will be executed in the next cycle.
If you have deselected a metadata type but it is still being deployed in CI jobs, then it could be because of a different name. Please verify that the folderName committed in Git is correct for the metadata. This should resolve the issue. If it doesn’t, contact our support team for further analysis.
You might have selected the option to Include default Apex tests for run test based on changes under Admin-->Salesforce settings, so even though there are no classes present in the package, it's still running default classes for code coverage. This is an expected behavior.
The reason you are unable to get the details of specific builds older than 3 months is due to ARM’s Retention Policy. There are some details which are archived and become unretrievable.
You can change the retention period to 6 months or 12 months from the Admin section of your ARM account.
The deployment may fail if it does not detect the metadata root folder path ‘src.’ Please update the Branch settings and then re-save the CI Job.
You can then perform a Merge Request to trigger the CI job and validate the deployment.
This may be a GIT behavior where the QuickAction metadata members are added and deleted again. As per GIT behavior, when it has to generate the delta between From and To revisions, in the case of a conflict, it skips such files from package preparation.
There is no Git logic under File Diff because it simply displays what was added/modified/deleted for better UI visibility to understand the changes and be reviewed.
You can work around this by updating the baseline revision CI job and using Single Revision in the Deployment module.
This could be due to using an older version of CodeScan. Refer to the CodeScan License Errors article for further information.
Last modified 1mo ago