Jenkins, problems with cm on Mac

[Evgeny]

I'm trying to setup iOS build on MacOS and checkout are failing with following error

[TestScripts] $ cm lwk --format={wkname}#{path}#{wkid}
FATAL: Cannot run program "cm" (in directory "/Volumes/LittleBigBOSS/JA1/workspace/TestJobs/TestScripts"): error=2, No such file or directory

 

Pipeline script is very simple and it works if i launch it on Windows Node

node('iOS')
{
    cm branch: context.BranchName, repository: context.SCMRepository, server: context.SCMServer
}

 

I checked all steps manually and they works.

1. cd to the path "/Volumes/LittleBigBOSS/JA1/workspace/TestJobs/TestScripts"
2. launched command "cm lwk --format={wkname}#{path}#{wkid}"

Here are shell log for this:

Last login: Fri May 15 23:28:59 on ttys000
bizon:~ admin$ cd /Volumes/LittleBigBOSS/JA1/workspace/TestJobs/TestScripts
bizon:TestScripts admin$ cm lwk --format={wkname}#{path}#{wkid}
default#/Users/admin/wkspaces/default#8b1b592b-f895-4377-b118-d4f1fa7fcbd0
bizon:TestScripts admin$ 

PS

Noticed, that i previously opened shell from admin user. Repeated test, using Jenkins user with same results

[Evgeny]

Maybe i did something wrong on the mac?

I just did another test.

Shell script executed from Jenkins pipeline "cm worspace create ..." returned "cm: command not found"

[Pipeline] sh
+ cm workspace create hc-smf-living-pictures-client /Volumes/LittleBigBOSS/JA1/workspace/hc-smf/hc-smf-living-pictures-client/hc-smf-living-pictures-client --repository=hc-smf/hc-smf-living-pictures-client@__@cloud
/Volumes/LittleBigBOSS/JA1/workspace/hc-smf/hc-smf-living-pictures-client@tmp/durable-62867457/script.sh: line 1: cm: command not found

I copyed the same command in bash and executed it manually and worspace was succesfully created

bizon:TestScripts jenkins$ cm workspace create hc-smf-living-pictures-client /Volumes/LittleBigBOSS/JA1/workspace/hc-smf/hc-smf-living-pictures-client/hc-smf-living-pictures-client --repository=hc-smf/hc-smf-living-pictures-client@__@cloud
Workspace hc-smf-living-pictures-client has been correctly created

What am i missing?

[calbzam]

Hi,

Could you manually copy the "/Users/xxx/plastic4/client.conf" to the client binaries folder?

/Applications/PlasticSCM.app/Contents/MonoBundle

The Jenkins server may be be run with a different user than yours. By Copying the configuration file in the client binaries folder, all the machine users will use the same Plastic clienbt configuration.

- Also review that "cm" is in the system PATH variable. You can also include the full path in the Jenkins configuration:

/Applications/PlasticSCM.app/Contents/MonoBundle/cm

Regards,

Carlos.

[Evgeny]

Jenkins server is running on Windows and i'm trying to setup agent on MacOS. So i can't use absolute path to cm - that will brake all windows builds.

What i tryed

- Reinstall Plastic under Jenkins user (Should'n this add cm to Path?)

- Add Plastic to /etc/paths 

/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
/Applications/PlasticSCM.app/Contents/MonoBundle

And it didn't work

bizon:TestScripts jenkins$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Applications/Xamarin Workbooks.app/Contents/SharedSupport/path-bin
bizon:TestScripts jenkins$ sudo open /etc/paths

- I tryed to execute cm in Bash (under Jenkins user) and it works. It seems, that cm is added to Path, but it only visible from Bash. And not visible from scripts.

[Evgeny]

I added all paths to the Agent Path variable and cm began to work trough the shell. It worth mentioning, that you can't add just Plastic path, as it will replace all other paths and event "sh" wouldn't be found.

But cm command from Jenkins Plugin are still failing with the same error.

[calbzam]

Hi,

I'm reviewing a previous ticket where we spent some tiem debugging the same error when using a Jenkins macOS ssh slave:
 

Quote

 

We've been debugging the issue. It seems to be a reported Jenkins bug affecting us:

https://issues.jenkins-ci.org/browse/JENKINS-17157

When configuring an ssh slave, the environment variables are not loaded. That's the reason why the Plastic "cm" is not being found (even if it's included in the PATH variable for the jenkins user in the MacOS machine).

 

I've tested with the Java Web Start and I'm not able to reproduce the issue:

On the macOS:
- Running:
sudo java -jar agent.jar -jnlpUrl http://MySERVER84/computer/macOsJava/slave-agent.jnlp -secret f5dcf86e0ceed3f22c08bc27fa07d680aff3e11c25452677af4fee218bcfb1aa -workDir "/tmp"

- I'm not using ssh for login.

I can successfully run a build with this configuration. 

 

 

Using the following workaroud the user was able to configure the PATH variable to include "mono" and the "cm" when connecting via SSH:

https://support.cloudbees.com/hc/en-us/articles/229724088-How-to-set-up-a-Jenkins-agent-to-have-the-same-path-as-the-user-when-connected-via-Remote-Desktop-

Regards,

Carlos.

[Evgeny]

Thank you.

I will setup all build process first, using shell. And in a few days i will check that workaround.

[Wildworks_Dev]

I'm running into this problem as well.  I have a fresh installation of Jenkins, running on a Mac Mini (Big Sur, installed with home-brew) and am getting the same error message. Of note, I have added

/Applications/PlasticSCM.app/Contents/MonoBundle

to my PATH, and I also copied over the client.conf file to the client binaries folder.

Interestingly enough, the "Check" button in the Manage Jenkins --> Configure System --> Plastic SCM actually validates and I get a success back.  However, I still get an error when running a job with the plastic plugin.  (same as mentioned above).

Would love to get this figured out.  Thanks!

[calbzam]

HI,

Quote

 

We've been debugging the issue. It seems to be a reported Jenkins bug affecting us:

https://issues.jenkins-ci.org/browse/JENKINS-17157

When configuring an ssh slave, the environment variables are not loaded. That's the reason why the Plastic "cm" is not being found (even if it's included in the PATH variable for the jenkins user in the MacOS machine).

 

I've tested with the Java Web Start and I'm not able to reproduce the issue:

On the macOS:
- Running:
sudo java -jar agent.jar -jnlpUrl http://MySERVER84/computer/macOsJava/slave-agent.jnlp -secret f5dcf86e0ceed3f22c08bc27fa07d680aff3e11c25452677af4fee218bcfb1aa -workDir "/tmp"

- I'm not using ssh for login.

I can successfully run a build with this configuration. 

 

Can you try this worakround?

Regards,

Carlos.

[Wildworks_Dev]

We're not configuring an SSH Slave, or as a slave at all - does that matter?  The work around is to not use a launch agent to start the Jenkins process, but rather use the Java Web Start command?  

Reading up on the "Java Web Start" command, it appears that that is only used if I'm setting up this Jenkins instance as a remote node (slave), which again I am not.  

Additionally, from my reading, the agent.jar file is generated by the Jenkins Master, when I go to set up a slave --> which again, isn't how we're running our Jenkins instance, so I don't think your "work around" is a work around for me.

[calbzam]

Hi,

I'm not a Jenklins expert. But as far as I know, you will need a a Jenkins agent to run a job, right?

https://adamtheautomator.com/jenkins-agent/

Quote

A Jenkins agent is an executable, residing on a node, that is tasked by the controller to run a job. Managing the different Jenkins agents is the job of the agent controller, also known as the master node. In a single Jenkins node configuration, the controller, can also act as both a Jenkin agent and run build jobs.

You should be able to use the Java Web Start agent to run your Jenkins jobs even if you are not using an external node for that purpose.

Regards,

Carlos.

[lrg_steven]

Did this solution work? The cm integration for Jenkins fails out of the box still on macOS. Since we're just running it as master, the fastest fix was to specify the executable in

Manage Jenkins > Configure System > Plastic SCM > Command Line Client Executable: /usr/local/bin/cm

You can access it using sh if you add it to the path in your pipeline script

environment { 
	PATH="/usr/local/bin:$PATH"
}

Note that updating the path in the script does not fix the original plugin issue.