Salesforce Freestyle CLI job returning special characters and build fails

Using Jenkins Ask a question
1

Hey all.

We are in a bind here. This is kind of necessary to get fixed. We are running shell scripts on our Jenkins server that communicate between BitBucket and our Salesforce orgs. They were working as of yesterday but today they are failing. We updated the SF CLI from 2.15.9 to the latest but it should not be doing what you’re seeing here.

Here is an example of a success:

  • sf org login jwt -i **** -o […user…] -f […keyfile…] -r […sbox url…] -s -a UAT
    Successfully authorized sa.jenkins@optiv.com.UAT with org ID […orgId…]

Now for the failed one:
e[1me[32mSuccessfully authorized […user…] with org ID 00Dbc000001K79dEACe[39me[22m

Any thoughts on what caused this? We are reimaging the server to a previous build and hopefully that will fix the issue but I need to know the underlying cause so we do not replicate this. issue

Jenkins setup:

Jenkins: 2.479.2
OS: Windows Server 2019 - 10.0
Java: 17.0.10 - Oracle Corporation (Java HotSpot™ 64-Bit Server VM)

active-directory:2.38
antisamy-markup-formatter:162.v0e6ec0fcfcf6
apache-httpcomponents-client-4-api:4.5.14-208.v438351942757
asm-api:9.7.1-97.v4cc844130d97
aws-lambda:0.5.10
bootstrap5-api:5.3.3-1
bouncycastle-api:2.30.1.79-254.vfdb_814e7791e
caffeine-api:3.1.8-133.v17b_1ff2e0599
checks-api:2.2.1
command-launcher:116.vd85919c54a_d6
commons-lang3-api:3.17.0-84.vb_b_938040b_078
commons-text-api:1.12.0-129.v99a_50df237f7
credentials:1405.vb_cda_74a_f8974
credentials-binding:687.v619cb_15e923f
dark-theme:514.va_3ea_73d65dc1
dashboard-view:2.523.v673d549dfee5
display-url-api:2.209.v582ed814ff2f
echarts-api:5.5.1-5
eddsa-api:0.3.0-4.v84c6f0f4969e
email-ext:1866.v14fa_6d201654
font-awesome-api:6.6.0-2
generic-webhook-trigger:2.2.5
gson-api:2.11.0-85.v1f4e87273c33
instance-identity:201.vd2a_b_5a_468a_a_6
ionicons-api:74.v93d5eb_813d5f
jackson2-api:2.17.0-379.v02de8ec9f64c
jakarta-activation-api:2.1.3-1
jakarta-mail-api:2.1.3-1
javax-activation-api:1.2.0-7
javax-mail-api:1.6.2-10
jaxb:2.3.9-1
jdk-tool:80.v8a_dee33ed6f0
jquery3-api:3.7.1-2
json-api:20240303-101.v7a_8666713110
json-path-api:2.9.0-118.v7f23ed82a_8b_8
junit:1312.v1a_235a_b_94a_31
mailer:489.vd4b_25144138f
matrix-project:840.v812f627cb_578
mina-sshd-api-common:2.14.0-138.v6341ee58e1df
mina-sshd-api-core:2.14.0-138.v6341ee58e1df
plain-credentials:183.va_de8f1dd5a_2b_
plugin-usage-plugin:4.8
plugin-util-api:5.1.0
resource-disposer:0.25
reverse-proxy-auth-plugin:238.v82ceca_8417a_6
role-strategy:743.v142ea_b_d5f1d3
scm-api:698.v8e3b_c788f0a_6
script-security:1369.v9b_98a_4e95b_2d
snakeyaml-api:2.3-123.v13484c65210a_
ssh-credentials:349.vb_8b_6b_9709f5b_
sshd:3.330.vc866a_8389b_58
structs:338.v848422169819
theme-manager:262.vc57ee4a_eda_5d
timestamper:1.28
token-macro:400.v35420b_922dcb_
trilead-api:2.147.vb_73cc728a_32e
variant:60.v7290fc0eb_b_cd
workflow-api:1336.vee415d95c521
workflow-step-api:678.v3ee58b_469476
workflow-support:936.v9fa_77211ca_e1
ws-cleanup:0.48

2

Was it working when you used version 2.15.9 of the SF CLI and is failing after updating it?
And is the job really failing? Are you parsing the output of the command in some way?
Normally it is only the return code of the script that leads to a build failure.
The different output is probably caused by the sf command now using ansi color codes (so when you’re in a shell you get colored output). There is the ansicolor plugin that would allow you to display the output in Jenkins also with colors.
Maybe the sf command has some kind of option for a batch mode (so it doesn’t use the ansi color codes in the output.

3

Yeah we addressed the weird characters setting the color code variable to I believe it was none. The characters did not show back up in the log but the job failed.

It was working on the 2.15.9 version so, with SF Support and our internal IT team, we re-imaged the server back to an image where the jobs were working and they work again.

I am assuming something in the new CLI is not working with the web service itself. I can do commands on the server through RDC and also on my personal laptop without any issues. We have another remote server that I will be getting back on line next week to test the CLI version over there and see if I get the same results.

4

The problem is keeping things up to date so we do not have any security flags. Some plugins cause those when they are in need of upgrades.

When updating things like plugins or CLI versions, the running of the job should not be affected so we are still wondering what the underlying cause is. Any insights would be greatly appreciated.