Troubleshooting Jenkins Plugin

If you run into installation or upgrade issues, consider the following troubleshooting scenarios.

Unauthorized error

Description: Unauthorized error.

Remedy:

• If you use basic authentication: make sure that the username-password combination on the web login is correct.

  If federated authentication is enabled, make sure you write the username in the task as “DOMAIN\user”

• If you use token authentication:

  • Revoke the token from the API access panel and generate a new one.
  • Make sure that the user that generated the key can access the Orchestrator and has a user account on the Orchestrator instance.
• If you authenticate against an on-premise Orchestrator: make sure that the Orchestrator certificate is valid and that the machine running the job trusts the Orchestrator certificate in case you are using a self-signed certificate. You might receive this error because of the certificate used for the Orchestrator not being valid. This might mean that it has the wrong CN or other validation issues.

Forbidden error

Remedy: the user doesn't have the permission to perform the action. Make sure that the user has permissions to read folders, upload packages, create and update processes, read test sets and test cases, read background tasks, and create and run test sets.

Folder/environment not found

Remedy: Make sure that the authenticated user used by CI/CD plugins has the Folders.View and BackgroundTask.View (only for 20.4) permissions.

Package already exists (Conflict)

Remedy: Make sure that the package that you are trying to deploy does not exist with the same version already. If it exists, consider using automatic package versioning, so that the new version is bumped up every time we deploy.

Failed to run the command (Generic error)

Remedy: If the Jenkins workspace is inside a location on disk (for example, C:\Windows or C:\Program Files) to which the user does not have permissions, make sure that the workspace is placed on a path that can be accessed by the user.

Jenkins fails to process paths containing non-Latin characters

Remedy: Jenkins is not able to pass correctly non-standard encoded characters when invoking the UiPath Plugin. The unknown characters will be replaced by ???.

The solution depends on how Jenkins is deployed on both the server and the agent host machines, but involves setting file.encoding to UTF-8 in Java options:

Windows

When running Jenkins on Windows as a Service: in the service configuration file add the arguments inside the tag. Follow the sample script below.

<arguments>-Xrs -Xmx512m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dfile.encoding=UTF-8 -jar "%BASE%\)\)jenkins.war" --httpPort=8080 --webroot="%BASE%\)\)war"</arguments>

When running Jenkins inside Docker: pass the JAVA_OPTS to the container via --env JAVA_OPTS="...", following the example script below.

docker run --name myjenkins -p 8080:8080 -p 50000:50000 --env JAVA_OPTS=-Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dfile.encoding=UTF-8 jenkins/jenkins:lts

When running Jenkins inside Tomcat: use environment variable CATALINA_OPTS. Follow the example script below.

export CATALINA_OPTS="-DJENKINS_HOME=/path/to/jenkins_home/ -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dfile.encoding=UTF-8 -Xmx512m"

Linux

When running on Debian or Ubuntu-based Linux distributions: in the configuration file search for the argument JAVA_ARGS, and add the file encoding. Follow the example script below:

JAVA_ARGS="-Dfile.encoding=UTF-8 -Xmx512m"

When running on RedHat Linux-based distributions: in the configuration file search for the argument JENKINS_JAVA_OPTIONS and add the file encoding. Follow the sample script below.

JENKINS_JAVA_OPTIONS="-Dfile.encoding=UTF-8 -Xmx512m"