Ant/Jenkins/Salesforce Pipeline Failing After Salesforce Sandbox Refreshes

Using Jenkins
1

Hello,

We are experiencing a very recent issue with our Ant/Jenkins/Salesforce CI/CD pipeline.

Starting with Salesforce sandbox refreshes just shortly before 3/1/2024, we are unable to successfully poll for deployment validation results through Jenkins. Our Jenkins job correctly triggers a deployment validation in the destination Salesforce sandbox and a deployment id is returned to the Jenkins console output, however, subsequent polling for deployment validation progress and end results fail. Once the deployment id is returned, the Jenkins console output runs endlessly, even though the deployment in the sandbox continues as normal and eventually completes.

Prior to the refresh of the Salesforce sandbox at the end of a jenkins pipeline, our console output for a validation running to the Salesforce sandbox looked like this:

validateLocalTests:
[sf:deploy] [WSC][Launcher.main:113]Please update the client to a JDK version that includes a fix for JDK-8209178.
[sf:deploy] Request for a deploy submitted successfully.
[sf:deploy] Request ID for the current deploy task: 0Af8G00001JvJBtSAN
[sf:deploy] Waiting for server to finish processing the request…
[sf:deploy] Request Status: Pending
[sf:deploy] Request Status: InProgress (225/11268) – Processing Type: ApexPage
[sf:deploy] Request Status: InProgress (350/11268) – Processing Type: Queue
[sf:deploy] Request Status: InProgress (1380/11268) – Processing Type: CustomObject
[sf:deploy] Request Status: InProgress (1380/11268) – Processing Type: CustomObject
[sf:deploy] Request Status: InProgress (6563/11268) – Processing Case.controller Case
[sf:deploy] Request Status: InProgress
[sf:deploy] Request Status: InProgress (7858/11268) – Processing Type: EmailTemplate
[sf:deploy] Request Status: InProgress (8201/11268) – Processing Type: CustomMetadata
[sf:deploy] Request Status: InProgress (10102/11268) – Processing Type: Flow
[sf:deploy] Request Status: InProgress (10406/11268) – Processing Type: ApexClass
[sf:deploy] Request Status: InProgress (10406/11268) – Processing Type: ApexClass
[sf:deploy] Request Status: InProgress (10406/11268) – Processing Type: ApexClass
[sf:deploy] Request Status: InProgress
[sf:deploy] Request Status: InProgress
[sf:deploy] Request Status: InProgress
[sf:deploy] Request Status: InProgress (5/1232) – Running Test: AARCreateRelatedRequestsTest.testAutoCreateATOPFromBusRev

Now, after any refresh of a Salesforce sandbox at the end of a Jenkins pipeline, our Jenkins console output for a validation running to the Salesforce sandbox looks like this:

validateLocalTests:
[sf:deploy] [WSC][Launcher.main:113]Please update the client to a JDK version that includes a fix for JDK-8209178.
[sf:deploy] Request for a deploy submitted successfully.
[sf:deploy] Request ID for the current deploy task: 0Af7700000EfWXtCAN
[sf:deploy] Waiting for server to finish processing the request…
[sf:deploy] Request Status: Pending
[sf:deploy] Failed to check the status for request ID=0Af7700000EfWXtCAN. Error: Failed to send request to https://aruplab--dev.sandbox.my.salesforce.com/services/Soap/m/59.0/00D770000000NCK. Retrying…

This continues on and on in the console output.

Clicking on the link in the error log navigates us to an Error 405 page:
HTTP ERROR 405
Problem accessing /services/Soap/m/59.0/00D8D000001MJGt. Reason: Only POST allowed

This is consistent. Every sandbox that we refresh at the end of an Ant/Jenkins pipeline now polls like this. The sandboxes we do not refresh, continue to poll correctly. The Salesforce version Spring '24 between all the boxes. To try to resolve, we have:

  • updated Jenkins to the most current version (initially we were on an older version, now we are on the newest version, however the issue still persists). Meaning the issue appears to be Jenkins version agnostic.
  • toggled the sandbox at the end of a Jenkins pipeline from a refreshed one to a older, non-refreshed one (same Salesforce version however) and seen that the console output toggles between failed polling for the refreshed sandbox and successful polling for the non-refreshed sandbox, as expected. Meaning the issue appears to be within the refreshed sandbox context.
  • ran an Ant validation command outside of the Jenkins context to a refreshed sandbox and that polls correctly. Meaning the issue appears to be within the Jenkins context.
  • updated our Ant package to the newest version, 59.0. Meaning the issue appears to be Ant version agnostic.
  • reached out to Salesforce to see if anything appears different in their deployment logs between a successful sandbox poll and a refreshed (unsuccessful) sandbox poll (nothing appears different on their end).

Things left to try:

  • update Java version to the latest JDK (JDK 17)
  • try with a new jenkins installation

In the meantime, has anyone seen/experienced this kind of issue and inconsistency after refreshing sandboxes before?

2

We believe we’ve narrowed the issue down to the server hosting Jenkins which is behind a firewall. When we ran an Ant command to validate to a Salesforce sandbox outside the context of a Jenkins job, so directly through command prompt window, then regardless if its refreshed or not refreshed sandbox, the validation progress polling looks as expected. However, when we run the same Ant command from a command prompt window directly on the server that hosts Jenkins, which is behind a firewall, then we only see successful validation progress polling for “not refreshed” sandboxes. For refreshed sandboxes, we see the same failing validation polling messages in the command prompt console output. To us, this suggests the issue is on the server/firewall side, since we are running the commands outside the Jenkins context but directly from the server hosting Jenkins. The server can successfully send a message out from the Jenkins job to start the sandbox validation, but it can’t receive the polling messages back to display in the Jenkins console output.

3

We think we resolved this by updating the Java version that is used by Jenkins jobs themselves to the latest JDK (JDK 17) in the JAVA_HOME variable in the “Manage Jenkins > Tools > JDK Installations” area. This doesn’t appear to be the same JAVA_HOME that the Jenkins program itself uses. That is still pointed at the old JDK (JDK 11) via the system environment variables because we still see a warning on the “Manage Jenkins” landing page that Java JDK 11 support will be deprecated Sep. 30, 2024.

We are not able to say why Jenkins jobs were able to run successfully to old sandboxes but not to new refreshed sandboxes when the JAVA_HOME variable in the “Manage Jenkins > Tools > JDK Installations” area is pointed at the old JDK 11, however, updating this variable to point to JDK 17 does make it so the same Jenkins jobs run to both newly refreshed sandboxes and old sandboxes.