jenkinsci / jfrog-plugin Goto Github PK

Describe the bug

Defining a server under Manage Jenkins | Configure System with a unique ID and its URL but without credentials, and in pipelines edit the configuration to add user/password, then subsequent 'jf' calls complaint about not finding the server URL.

Current behavior

[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] jf
[arti_test] $ docker exec --env ******** --env ******** f833c477775786725f2cca26fc80cc1f1bac9f61ce7119c2066189617626e808 /opt/jenkins/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf c add arti_server --user= ******** --url=https://my_art_server.com --artifactory-url=https://my_art_server.com/artifactory --distribution-url=https://my_art_server.com/distribution --xray-url=https://my_art_server.com/xray --interactive=false --overwrite=true
14:04:12 [Debug] JFrog CLI version: 2.53.2
14:04:12 [Debug] OS/Arch: linux/amd64
14:04:12 [Debug] Locking config file to run config AddOrEdit command.
14:04:12 [Debug] Creating lock in: /opt/jenkins/workspace/arti_test@tmp/jfrog/10/.jfrog/locks/config
14:04:12 [Debug] Releasing lock: /opt/jenkins/workspace/arti_test@tmp/jfrog/10/.jfrog/locks/config/jfrog-cli.conf.lck.9.1710338652958460070
14:04:12 [Debug] Config AddOrEdit command completed successfully. config file is released.
[arti_test] $ docker exec --env ******** --env ******** f833c477775786725f2cca26fc80cc1f1bac9f61ce7119c2066189617626e808 /opt/jenkins/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf config show
14:04:13 [Debug] JFrog CLI version: 2.53.2
14:04:13 [Debug] OS/Arch: linux/amd64
Server ID: arti_server
JFrog Platform URL: https://my_art_server.com/
Artifactory URL: https://my_art_server.com/artifactory/
Distribution URL: https://my_art_server.com/distribution/
Xray URL: https://my_art_server.com/xray/
Mission Control URL: https://my_art_server.com/mc/
Pipelines URL: https://my_art_server.com/pipelines/
Default: true

[Pipeline] jf
[arti_test] $ docker exec --env ******** --env ******** f833c477775786725f2cca26fc80cc1f1bac9f61ce7119c2066189617626e808 /opt/jenkins/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf config edit arti_server --user=my_user --password=***
14:04:13 [Debug] JFrog CLI version: 2.53.2
14:04:13 [Debug] OS/Arch: linux/amd64
14:04:13 [Debug] Locking config file to run config AddOrEdit command.
14:04:13 [Debug] Creating lock in: /opt/jenkins/workspace/arti_test@tmp/jfrog/10/.jfrog/locks/config
14:04:13 [Debug] Releasing lock: /opt/jenkins/workspace/arti_test@tmp/jfrog/10/.jfrog/locks/config/jfrog-cli.conf.lck.28.1710338653130701623
14:04:13 [Debug] Config AddOrEdit command completed successfully. config file is released.
[Pipeline] jf
[arti_test] $ docker exec --env ******** --env ******** f833c477775786725f2cca26fc80cc1f1bac9f61ce7119c2066189617626e808 /opt/jenkins/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf config show
14:04:13 [Debug] JFrog CLI version: 2.53.2
14:04:13 [Debug] OS/Arch: linux/amd64
Server ID: arti_server
User: my_user
Password: ***
Default: true

[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build and Publish)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] jf
[arti_test] $ docker exec --env ******** --env ******** f833c477775786725f2cca26fc80cc1f1bac9f61ce7119c2066189617626e808 /opt/jenkins/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf mvn --project ${PROJECT_ID} clean install
14:04:20 [Debug] JFrog CLI version: 2.53.2
14:04:20 [Debug] OS/Arch: linux/amd64
14:04:20 [Debug] Saving build general details at: /tmp/jfrog/builds/33ca3cae3fe1ba0994026d5b733bfaf6ff380687333fbea68dfce8c634937b79/partials
14:04:20 [Error] Server ID arti_server: URL is required.

Reproduction steps

Add a server configuration under Manage Jenkins > Configure System as described in the doc but without credentials.
Add pipeline steps:

        stage('Edit JFrog CLI') {
            steps {
                jf('config show')
                jf('config edit arti_server --user=my_user --password=***')
                jf('config show')
            }
        }

        stage('Build and Publish') {
            steps {
                jf('mvn --project ${PROJECT_ID} clean install')
            }
        }

Expected behavior

The user and password should be add to configuration without removing server URLs

JFrog plugin version

1.5.0

JFrog CLI version

2.53.2

Operating system type and version

Linux

JFrog Artifactory version

7.68.19

JFrog Xray version

No response

Describe the bug

When uploading artefacts from a build following a git checkout, the JFrog plugin (using "rtUpload") appends the values of Jenkin's GIT_* environment variables to the URL causing an HTTP 404 error.

Current behavior

The current behaviour is a systematic HTTP 404 (Not Found) error.
The only workaround seems to be to unset all GIT_* environment variables:
environment { GIT_BRANCH = "" GIT_COMMIT = "" GIT_PREVIOUS_COMMIT = "" GIT_PREVIOUS_SUCCESSFUL_COMMIT = "" GIT_URL = "" }

Reproduction steps

No response

Expected behavior

No response

JFrog plugin version

1.5.0

JFrog CLI version

N/A

Operating system type and version

CentOS 7.9

JFrog Artifactory version

6.23.42 rev 62342900

JFrog Xray version

No response

How can we help?

Hallo, developers team. I am facing with problem with my Jenkins could not download tool from releases.jfrog.io:

I debug console from my pipeline and have some message:

java.net.UnknownHostException: No such host is known (releases.jfrog.io)

Describe the bug

Using Amazon Corretto Java 11, it reports the OS architecture (-Dos.arch=aarch64) on my Mac-Mini (arm64 processor). Thus, the evaluation of the jf binary to download for the tool section fails to match the expected "arm64" adn thus downloads the mac-386 binary.

uname -a
Darwin macmini2-ab6-31.qanmw.com 21.6.0 Darwin Kernel Version 21.6.0: Thu Mar  9 20:10:19 PST 2023; root:xnu-8020.240.18.700.8~1/RELEASE_ARM64_T8101 arm64

java -XshowSettings:properties -version
Property settings:
    awt.toolkit = sun.lwawt.macosx.LWCToolkit
    file.encoding = UTF-8
    file.separator = /
    ftp.nonProxyHosts = local|*.local|169.254/16|*.169.254/16
    gopherProxySet = false
    http.nonProxyHosts = local|*.local|169.254/16|*.169.254/16
    java.awt.graphicsenv = sun.awt.CGraphicsEnvironment
    java.awt.headless = true
    java.awt.printerjob = sun.lwawt.macosx.CPrinterJob
    java.class.path = 
    java.class.version = 55.0
    java.home = /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
    java.io.tmpdir = /var/folders/vw/nptbkkh90s38zt1tx9spqjx00000gn/T/
    java.library.path = /Users/netmotiontest/Library/Java/Extensions
        /Library/Java/Extensions
        /Network/Library/Java/Extensions
        /System/Library/Java/Extensions
        /usr/lib/java
        .
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 11.0.19+7-LTS
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation
    java.specification.version = 11
    java.vendor = Amazon.com Inc.
    java.vendor.url = https://aws.amazon.com/corretto/
    java.vendor.url.bug = https://github.com/corretto/corretto-11/issues/
    java.vendor.version = Corretto-11.0.19.7.1
    java.version = 11.0.19
    java.version.date = 2023-04-18
    java.vm.compressedOopsMode = Zero based
    java.vm.info = mixed mode
    java.vm.name = OpenJDK 64-Bit Server VM
    java.vm.specification.name = Java Virtual Machine Specification
    java.vm.specification.vendor = Oracle Corporation
    java.vm.specification.version = 11
    java.vm.vendor = Amazon.com Inc.
    java.vm.version = 11.0.19+7-LTS
    jdk.debug = release
    line.separator = \n 
    os.arch = aarch64
    os.name = Mac OS X
    os.version = 12.6.5
    path.separator = :
    socksNonProxyHosts = local|*.local|169.254/16|*.169.254/16
    sun.arch.data.model = 64
    sun.boot.library.path = /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home/lib
    sun.cpu.endian = little
    sun.cpu.isalist = 
    sun.io.unicode.encoding = UnicodeBig
    sun.java.launcher = SUN_STANDARD
    sun.jnu.encoding = UTF-8
    sun.management.compiler = HotSpot 64-Bit Tiered Compilers
    sun.os.patch.level = unknown
...

Current behavior

pipeline {
...
   stage('MacOSX') {
       agent {
           label 'macos' 
       }
       tools {
           jfrog = 'jfrog-cli'
       }
       ...
       stages {
           stage("publish") {
               jf 'rt upload ...'
               ...
           }
       }
}

Results into a failed stage for publish.

java.io.IOException: error=86, Bad CPU type in executable
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)

Reproduction steps

Run a jenkins pipeline on a mac-mini (arm-64) machine.

Expected behavior

JFrog plugin should download the correct jf executable for the platform.

JFrog plugin version

1.4.0

JFrog CLI version

2.40

Operating system type and version

Mac Min running 12.6.5, architecture arm64, Amazon Coretto Java 11

JFrog Artifactory version

No response

JFrog Xray version

No response

Is your feature request related to a problem? Please describe.

I noticed that artifactory plugin can provide a build bagde, that we can click the link to jump to jfrog to view the specific build info.
I think this function is very useful and I really like it.
But in reality, we use jfrog cli to build, collect build info, publish build info.
So I hope that there is an independent step to add the build info badge.

Describe the solution you'd like to see

Add a BuildInfoBadgeStep.

Describe alternatives you've considered

No response

Additional context

No response

Describe the bug

When calling jf "gradle <something>" in a Jenkins pipeline, with --use-wrapper=true it fails with an 'unexpected error'

jf gradle clean artifactoryPublish
18:01:47 [Info] Running gradle...
18:01:47 [Info] Running gradle command: ./gradlew --version
18:01:47 [Error] unexpected error occurred during attempt to get the Gradle version: NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED

We assume that the jfrog-plugin does not find java, although the environment variable is set and it can be called by shell within the step.

Current behavior

Our script:

script {
    dir('/opt/xxx/data/jenkins/workspace/Test-JF/xray-demo') {
        withEnv(["JAVA_HOME=/opt/xxx/jdk11.0.11_9"]) {
            env.JAVA_HOME = '/opt/xxx/jdk11.0.11_9'
            env.PATH="${env.JAVA_HOME}/bin:${env.PATH}"
            sh "env" //shows correct JAVA_HOME and PATH
            sh "java --version" //executes
            sh "cp /opt/xxx/bin/jf ." //to make sure the context is right. but doesn't change anything
            sh "chmod +x ./jf"
            sh "ls -al"
            sh "./jf c add xxx-artifactory --user=srvGIT-SELECT --url=https://repo.xxx.local --artifactory-url=https://repo.xxx.local/artifactory --distribution-url=https://repo.xxx.local/distribution --xray-url=https://repo.xxx.local/xray --interactive=false --overwrite=true"
           sh "./jf gradle-config --use-wrapper=true --repo-resolve=xxx.maven.release --repo-deploy=xy.maven.staging.local --global --uses-plugin"
           def retVal = sh(script: """./jf gradle --build-name="test" --build-number="0.0.1" """, returnStdout: true)
           echo retVal
        }                         
    }
}

Which leads to output (shortend):

Started by user
Running on [Jenkins](https://jenkins:11001/jenkins/computer/(built-in)/) in /opt/xxx/data/jenkins/workspace/Test-JF
Running in /opt/xxx/data/jenkins/workspace/Test-JF/xray-demo
+ env
JAVA_HOME=/opt/xxx/jdk11.0.11_9
PATH=/opt/xxx/jdk11.0.11_9/bin:...
+ java --version
NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL- 
UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED -- 
add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
openjdk 11.0.11 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
+ cp /opt/xxx/bin/jf .
+ chmod +x ./jf
+ ls -al
drwxr-x--- 8 xxx yyy      256 20. Sep 22:50 .
drwxr-x--- 4 xxx yyy       44 20. Sep 12:47 ..
-rw-r----- 1 xxx yyy     2371 20. Sep 12:45 build.gradle
drwxr-x--- 8 xxx yyy      163 20. Sep 12:45 .git
-rw-r----- 1 xxx yyy      444 20. Sep 12:45 .gitignore
drwxr-xr-x 4 xxx yyy       32 20. Sep 14:54 .gradle
drwxr-x--- 3 xxx yyy       21 20. Sep 12:45 gradle
-rw-r----- 1 xxx yyy      402 20. Sep 12:45 gradle.properties
-rwxr-x--- 1 xxx yyy     8188 20. Sep 12:45 gradlew
-rw-r----- 1 xxx yyy     2747 20. Sep 12:45 gradlew.bat
-rw-r----- 1 xxx yyy     6473 20. Sep 12:45 Jenkinsfile
-rwxr-x--- 1 xxx yyy 26718552 20. Sep 23:02 jf
drwxr-x--- 3 xxx yyy       22 20. Sep 12:54 .jfrog
drwxr-x--- 2 xxx yyy      102 20. Sep 12:45 kubernetes
-rw-r----- 1 xxx yyy       81 20. Sep 12:45 README.md
-rw-r----- 1 xxx yyy       32 20. Sep 12:45 settings.gradle
drwxr-x--- 4 xxx yyy       30 20. Sep 12:45 src
+ ./jf c add xxx-artifactory --user=abc --url=https://repo.xxx.local/ --artifactory-url=https://repo.xxx.local/artifactory --distribution-url=https://repo.xxx.local/distribution --xray-url=https://repo.xxx.local/xray --interactive=false --overwrite=true
+ ./jf gradle-config --use-wrapper=true --repo-resolve=xxx.maven.release --repo-deploy=xy.maven.staging.local --global --uses-plugin
23:02:28 [Info] gradle build config successfully created.
+ ./jf gradle --build-name=test --build-number=0.0.1
23:22:32 [Debug] JFrog CLI version: 2.48.0
23:22:32 [Debug] OS/Arch: linux/amd64
23:22:32 [Debug] Usage Report: Sending info...
23:22:32 [Debug] Saving build general details at: /tmp/jfrog/builds/4eace77046a199e189022686bbd1f9c85369165d41c55781ea4f28c7f58bd095/partials
23:22:32 [Info] Running gradle...
23:22:32 [Info] Running gradle command: ./gradlew --version
23:22:32 [Debug] Sending HTTP GET request to: https://repo.xxx.local/artifactory/api/system/version
23:22:32 [Debug] Artifactory response: 200 OK
23:22:32 [Debug] JFrog Artifactory version is: 7.63.14
23:22:32 [Debug] Sending HTTP POST request to: https://repo.xxx.local/artifactory/api/system/usage
23:02:28 [Info] Running gradle...
23:02:28 [Info] Running gradle command: ./gradlew --version
23:22:32 [Error] unexpected error occurred during attempt to get the Gradle version: NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED    ERROR: script returned exit code 1
/opt/xxx/data/jenkins/workspace/Test-JF@tmp/jfrog/124/.jfrog deleted
Finished: FAILURE

The weird thing is: Calling all these steps from the bash on the hosting machine it works:

Reproduction steps

Jenkins: Version 2.414.1

We followed this description: https://plugins.jenkins.io/jfrog/#plugin-content-configuring-jfrog-cli-as-a-tool

• Installing the plugin
• Configuring the plugin
• Setting the path to jfrog cli executable to /opt/xxx/bin/ and call it xxx-artifactory
• Setting the tool
• Checking jf by calling jf "dl ..." which downloaded the desired file - works!
• And then trying the script above
• We also tried sh "jf ..." and sh(script: "jf gradle...", returnStdout: true)
• We checked permissions and ownership of files & folders.
• We copied the jf-cli locally

Expected behavior

Executing the gradle-wrapper from within the plugin.

JFrog plugin version

1.5.0

JFrog CLI version

2.48.0

Operating system type and version

Linux

JFrog Artifactory version

No response

JFrog Xray version

No response

Is your feature request related to a problem? Please describe.

I'd like the plugin to setup things such that the we can either use the jf function in a Jenkinsfile/job, and the jf shell command.

Describe the solution you'd like to see

We have a number of jobs that use a Makefile, or other build tool, to download assets from Artifactory. In order to make the jenkins build as close to a developer build as possible, we cannot rely on the jf function within the Jenkinsfile/job, but instead we want to reply on the jf shell command. This allows the Jenkins builds, and developer builds to be as close to repeatable as possible.

Describe alternatives you've considered

I have a Jenkins shared-library function that does this but it's clunky, may not be very portable.

Additional context

No response

Describe the bug

The jf step does not consider quotes when splitting an args string.

The following command works on the shell:

jf rt curl -XPUT -H "Content-Type: application/json" --upload-file buildinfo.json "/api/build" --server-id=af

The equivalent in a Jenkins pipeline fails:

jf('rt curl -XPUT -H "Content-Type: application/json" --upload-file buildinfo.json "/api/build" --server-id=af')

Workaround: Pass a list of arguments:

jf(['rt', 'curl', '-XPUT', '-H', "Content-Type: application/json", '--upload-file', 'buildinfo.json', "/api/build", '--server-id=af'])

Current behavior

The following pipeline step results in an error:

jf('rt curl -XPUT -H "Content-Type: application/json" --upload-file buildinfo.json "/api/build" --server-id=af')

The console output:

10:55:08    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
10:55:08                                   Dload  Upload   Total   Spent    Left  Speed
10:55:09  
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   799  100   435  100   364   5958   4986 --:--:-- --:--:-- --:--:-- 10945
10:55:09  <!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1></body></html>  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
10:55:09                                   Dload  Upload   Total   Spent    Left  Speed
10:55:09  
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: "

Reproduction steps

see description

Expected behavior

The header parameter value Content-Type: application/json should be treated as one argument and not two.

JFrog plugin version

1.2.0

JFrog CLI version

2.34.6

Operating system type and version

Debian

JFrog Artifactory version

JFrog Cloud

JFrog Xray version

No response

Is your feature request related to a problem? Please describe.

This feature request directly pertains to an issue we have been encountering. In our case, while using Jenkins for managing our builds and deployments, we need to ensure proper interaction with services that should not be utilizing a proxy. Currently, we are faced with two less than optimal solutions: either we set the global environment variable, which isn't always necessary and thus adds unnecessary overhead to our setup, or we explicitly define it for specific steps within our pipeline, which is also quite cumbersome and inefficient. Both these approaches add extra steps to our configuration and maintenance process. Hence, the ability to automatically fetch the no_proxy setting from Jenkins configuration would streamline our operations significantly.

Describe the solution you'd like to see

It would be greatly appreciated if you could implement the feature to get the no_proxy setting from the Jenkins configuration, in the same way it's currently done for http_proxy and https_proxy. This enhancement would significantly increase the versatility of the proxy setup.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

The Jenkins JFrog Plugin utilizes the JFrog Platform URL for connecting to Artifactory. However, when using PrivateLink, the execution results link reflects the PrivateLink address, preventing seamless navigation to JFrog's UI.

This link does not work since it is PrivateLink address, not JFrog UI address.

Describe the solution you'd like to see

Implement a feature that allows users to configure the link used for execution results. This would providing a field in the Jenkins JFrog Plugin settings where users can specify a custom URL for execution results

Describe alternatives you've considered

Nothing special

Additional context

No response

How can we help?

Looks like this issue is explained in jfrog/jfrog-cli#1616 (comment)

I can configure the plugin with user and password and all is fine. But when I use an access token the job fails with Unauthorized:
(All hostnames and account info removed)

The plugin runs this in the jenkins pipeline:

/usr/local/bin/jf c add artifactory --user=x --password x --url=xxxx --artifactory-url=https://xxxx --distribution-url=https://xxxx/distribution --xray-url=https://xxxx/xray --interactive=false --overwrite=true
[jenkins@john-jfrog-test ~]$ /usr/local/bin/jf rt ping
10:04:38 [🚨Error] server response: 401 Unauthorized
{
"errors": [
{
"status": 401,
"message": "Bad credentials"
}
]
}
[jenkins@john-jfrog-test ~]$

Adding the workaround from issue 1616 resolves the issue from the shell but how do I implement these options in the plugin?
"--enc-password=false --basic-auth-only"

/usr/local/bin/jf c add artifactory --user=x --password=x --url=https://xxxx --artifactory-url=https://xxxx/artifactory --distribution-url=https://xxxx/distribution --xray-url=https://xxxx/xray --interactive=false --overwrite=true --enc-password=false --basic-auth-only
[jenkins@john-jfrog-test ~]$
[jenkins@john-jfrog-test ~]$ /usr/local/bin/jf rt ping
OK

jf version 2.34.1
JFrog Plugin Version1.0.5

Thanks.

Describe the bug

On a rare occasion, happens often enough for me to file a bug, but maybe 1 in 10 builds or 1 in 20. The first step in trying to publish the build causes a build failure. The failure produces a stack-trace see "current behavior" box.

This is

• Jenkins 2.414.1
• JFrog Plugin 1.5.0
• Running the build on a remote Mac Mini running an ARM processor (same network as Jenkins instance)
• Jenkins is configured to fetch the latest version of JFrog from jfrog.com (or whatever the default is).
  NOTE: Tool is already installed / cached, I think this maybe the initial request to verify the latest version??

We have Artifactory installed in AWS with a load-balancer in front of it (split between two IPs).

Current behavior

Stack Trace when reproduced.

Timeout has been exceeded
java.lang.InterruptedException
	at java.base/java.lang.Object.wait(Native Method)
	at hudson.remoting.Request.call(Request.java:177)
	at hudson.remoting.Channel.call(Channel.java:999)
	at hudson.FilePath.act(FilePath.java:1192)
	at hudson.FilePath.act(FilePath.java:1181)
	at io.jenkins.plugins.jfrog.BinaryInstaller.performJfrogCliInstallation(BinaryInstaller.java:53)
	at io.jenkins.plugins.jfrog.ArtifactoryInstaller.performInstallation(ArtifactoryInstaller.java:67)
	at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:70)
	at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
	at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:221)
	at io.jenkins.plugins.jfrog.JfrogInstallation.forNode(JfrogInstallation.java:50)
	at io.jenkins.plugins.jfrog.JfrogInstallation.forNode(JfrogInstallation.java:32)
	at org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:157)
	at org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:138)
	at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: 94080efa-6c44-4d55-9085-928a2a7658f3
/var/lib/jenkins/jobs/Secure Access/workspace/Zappa2@tmp/jfrog/461/.jfrog deleted
Finished: ABORTED

Reproduction steps

Configure latest Jenkins 2.414.1 and JFrog Plugin 1.5.0. Add a Jenkins node running on a Mac Mini (ARM64 based). Create a pipeline script that will attempt e.g. dump 1Gb of data into a temporary file, then upload that file in a "publish" step that require jfrog-cli.

The initial installation (or verification of the version of this tool), causes the build to "hang" then eventually timeout. The timeout will cause an Interrupted exception showing the backtrace.

Expected behavior

There shouldn't be any hang when reaching out to jfrog checking version or fetching the new version of the jfrog-cli. If a response doesn't come in "reasonable" time, it should retry (just like the jfrog-cli) and then hopefully work??

JFrog plugin version

1.5.0

JFrog CLI version

2.44.1

Operating system type and version

OSX - 12.6.5 - Mac Mini running an Arm64 processor

JFrog Artifactory version

7.41.14

JFrog Xray version

n/a

Is your feature request related to a problem? Please describe.

I'm having trouble configuring this plugin when using Jenkins Configuration as Code. I've done my best looking at the plugin code to try to determine what my config should be, however when Jenkins starts up there is an issue.

Using the config below, Jenkins doesn't seem to pull in the install source and I always have to set it manually after a restart.

unclassified:
  jFrogPlatformBuilder:
    jfrogInstances:
      - serverId: "artifactory"
        platformUrl: https://mycompany.jfrog.io/
        credentialsConfig:
          credentialsId: "artifactory-account"
tool:
  jfrogInstallation:
    installations:
      - name: "jfrog-cli"
        home: ""
        properties:
          - installSource:
              installers:
                - releasesInstaller:
                    id: "latestJfrogInstaller"

(I'm aiming to have a very simple tool where it just grabs the latest from the releases site.)

I've also tried to use Jenkin's ability to show me the current JCasC after manually setting everything up, however I get a stack trace in the output instead of something helpful.

jFrogPlatformBuilder:
    jfrogInstances: |-
      FAILED TO EXPORT
      io.jenkins.plugins.jfrog.configuration.JFrogPlatformBuilder$DescriptorImpl#jfrogInstances: io.jenkins.plugins.casc.ConfiguratorException: Can't read attribute 'platformUrl' from io.jenkins.plugins.jfrog.configuration.JFrogPlatformInstance@1e23abad
        at io.jenkins.plugins.casc.Attribute._getValue(Attribute.java:461)
        at io.jenkins.plugins.casc.Attribute.getValue(Attribute.java:235)
        at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.describe(DataBoundConfigurator.java:289)
        at io.jenkins.plugins.casc.Attribute._describe(Attribute.java:328)
        at io.jenkins.plugins.casc.Attribute.describe(Attribute.java:257)
        at io.jenkins.plugins.casc.Configurator.describe(Configurator.java:183)
        at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:114)
        at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.lambda$describe$3(GlobalConfigurationCategoryConfigurator.java:107)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
        at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
        at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
        at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1845)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
        at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:107)
        at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:33)

The tool itself gives me very little when looking at the same screen:

tool:
  jfrog:
    installations:
    - name: "jfrog-cli"
  sonarRunnerInstallation:
    installations:
    - name: "sonarScanner"
      properties:
      - installSource:
          installers:
          - sonarRunnerInstaller:
              id: "4.7.0.2747"

(I included the output from Sonar Qube's tool to show what I think I'm looking for.

Describe the solution you'd like to see

It would be really nice to see an example of how to configure the "platform builder" and the "jFrog Installation" tool.

Describe alternatives you've considered

I've come as close as I can with Config. Currently, when a Job fails (after a jenkins restart) I have to login to jenkins and add the missing config...restart my job.

Additional context

No response

Is your feature request related to a problem? Please describe.

I'm trying to evaluate whether an artifact already exists on the repository I'm trying to upload to. To do so, I thought of using the jf rt search command, but as far as I can see, the the function is a void function.

Describe the solution you'd like to see

Return stdout of executed command so that it can be stored/interpreted in the following way (Jenkins declarative pipeline example):

script {
    String result = jf 'rt search --count <repository>/<file>'
    echo result
}

Describe alternatives you've considered

Since the jf execution is printed to the job's log, I could parse the log instead (or at least the last N lines). But this approach seems to be very hacky...

Describe the bug

Hello,

I use the jenkins master with a local proxy server (127.0.0.1:8080) to fetch plugins from outside of the local network. Artifactory is running on a local server, so no proxy needed in this case.

commit 3448dd9 forces nodes to inherit from controller proxy configuration and breaks at least jfrog client automatic installation.

Is it possible to add an option to disable proxy configuration, or eventually a no_proxy parameter to whitelist hosts on local network ?

Thank you.

Current behavior

Nodes try to connect to proxy 127.0.0.1:8080 which exists only on jenkins master.

Reproduction steps

No response

Expected behavior

No response

JFrog plugin version

1.2.0

JFrog CLI version

latest

Operating system type and version

rhel7

JFrog Artifactory version

No response

JFrog Xray version

No response

Describe the bug

We have setup the JFrog plugin to install the latest version of the jf CLI from our Artifactory SaaS instance - just as described in the plugin documentation: A generic repo connected to JFrog - which shows 'Remote Artifactory detected' - and the tools setup in Jenkins points to this repo and the version field is empty - which should mean latest version.

Current behavior

For some reason, Artifactory doesn't update the CLI client: The version found at <reponame>/v2-jf/[RELEASE]/jfrog-cli-linux-amd64/jf is stuck at 2.37.1. This is causing issues as the JFrog platform is being upgraded.

Reproduction steps

Download the RELEASE artifact from the above path: It invariably delivers 2.37.1.

Expected behavior

We would expect to get the latest version as per documentation.

JFrog plugin version

1.5.0

JFrog CLI version

2.37.1 :-)

Operating system type and version

Linux / Windows / Docker / Podman / Kubernetes

JFrog Artifactory version

Latest SaaS

JFrog Xray version

Latest SaaS

Describe the bug

I'm trying to run an npm build, publish build info, and execute xray scan while running inside a withDockerContainer block. However, after I try publishing the build info, a command to kick off an xray scan fails.

Current behavior

The jf 'npm i' works, then jf 'rt bp' runs without error, then jf 'bs' blows up saying it can't find the build info. When I check our artifactory, there was a build pushed but the build info doesn't have any of the metadata/dependencies from the npm install. I have a feeling from inspecting the job logs that the jfrog plugin/CLI might use environment variables tmp dirs to store build info, but they don't carry across the different commands

Reproduction steps

Run a pipeline job with steps similar to this scripted pipeline syntax:

node {
    withDockerContainer(
      image: 'node:18.17.1',
      args: "-v <tools_dir>:<tools_dir>:rw,z" // this was necessary so that the container could use the globally configured jfrog-cli tool
    ) {
        withEnv(["JFROG_BINARY_PATH=${tool 'jfrog-cli'}"]) {
            stage('Build and scan') {
                // checkout some npm project here
                jf 'npm-config --repo-resolve <resolve_repo> --repo-deploy <resolve_repo>'
                jf 'npm i'
                jf 'rt bp'
                jf 'bs' // 404 returned here
            }
        }
    }
}

Expected behavior

The build info should be populated and pushed correctly, allowing an xray scan to run against that build's dependencies.

JFrog plugin version

1.4.0

JFrog CLI version

2.45.0

Operating system type and version

Amazon Linux / UBI

JFrog Artifactory version

7.49.6

JFrog Xray version

3.66.6

Hey ya'll, I'm trying to get this plugin working with Docker agents and can't seem to get the plugin working inside a docker container.

What I've tried to do is something like the following:

pipeline {
    agent any
    stages {
        stage ('Testing') {
            agent {
                docker {
                    image "maven:3.8.6-eclipse-temurin-17"
                    reuseNode true
                }
            }

            tools {
                jfrog 'jfrog-cli'
            }

            steps {
                jf "mvn clean compile install"
            }
        }
    }
}

I've also tried using the other docker agent context

docker.image("maven:3.8.6-eclipse-temurin-17") {
    jf "mvn clean compile install"
}

And the docker container has issues finding the jfrog-cli binaries that are downloading into the Jenkins job workspace. I end up getting errors like (I've modified the log message slightly to obscure my environment):

13:10:37  $ docker run -t -d -u 1002:998 -w /tmp/jenkins-a191ea73/workspace/PROJECT -v /tmp/jenkins-a191ea73/workspace/PROJECT:/tmp/jenkins-a191ea73/workspace/PROJECT:rw,z -v /tmp/jenkins-a191ea73/workspace/PROJECT@tmp:/tmp/jenkins-a191ea73/workspace/PROJECT@tmp:rw,z ... maven:3.8.6-eclipse-temurin-17 cat
13:10:39  $ docker top 0592567f0bd2148f376bf9928310e6923c3cd2c2847902d322493f407d811e92 -eo pid,comm
[Pipeline] {
[Pipeline] tool
13:34:54  Download 'jf' latest version from: https://releases.jfrog.io/artifactory/jfrog-cli/v2-jf/[RELEASE]/jfrog-cli-linux-amd64/jf
...
[Pipeline] jf
13:10:39  $ docker exec ... 0592567f0bd2148f376bf9928310e6923c3cd2c2847902d322493f407d811e92 /tmp/jenkins-a191ea73/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf c add jfrog-artifactory --user=USER ******** --url=https://URL.jfrog.io/ --artifactory-url=https://URL.jfrog.io/artifactory --distribution-url=https://URL.jfrog.io/distribution --xray-url=https://URL.jfrog.io/xray --interactive=false --overwrite=true
13:10:39  OCI runtime exec failed: exec failed: unable to start container process: exec: "/tmp/jenkins-a191ea73/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf": stat /tmp/jenkins-a191ea73/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf: no such file or directory: unknown

I'm assuming this happens because the JFrog CLI file that's downloaded in the tools step is being installed/configured on the Jenkins host agent and not on the Docker agent itself. Then when running the docker container the context of the JFrog CLI isn't propagated to the docker container correctly.

I could mount the volume of where the JFrog CLI tool gets download, but this still causes some configuration issues of where the jf step expects the CLI from within the container to run. I also don't think it's easy to get /tmp/jenkins-a191ea73/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf dynamically, so it may not be ideal to do this. EDIT: I found there's a variable JFROG_BINARY_PATH that points to this directory location, so I'm playing around with mounting this directory into the docker container.

Wondering if there's any recommended approach to using the plugin this way, or if there's planned support in the future for using docker with this plugin?

I will mention I was testing out using the new plugin while trying to migrate off of the old one. We're currently using the old JFrog plugin with rtMavenRun like this within a docker container and it works as we'd expect.

Thanks in advance, let me know if I can provide any additional information for investigating this further.

How can we help?

I am not sure if this should be an enhancement request or a question, but is there a way to add an interactive build-promotion request using the new 'jfrog-plugin', i.e. instead of using addInteractivePromotion() from the declarative pipeline?

Is your feature request related to a problem? Please describe.

Consider the following use case where we are running a multi-branch pipeline that is having 3 new branches within it(i.e branch1, branch2, and master maintaining the same build name & number) and maintain a single buildinfo object in Artifactory by publishing it from each branch.

1. Publish buildinfo of the first pipeline branch to Artifactory
2. Then, download the existing buildinfo of the above build from Artifactory and append it to the current buildinfo of the next branch, and publish it again to Artifactory.
3. Similarly, download the latest buildinfo (for the above build number) from Artifactory and append it to the current buildinfo, and publish it to Artifactory.

Describe the solution you'd like to see

Currently, appending a published build-info into an unpublished build-info is not supported. Hence, Looking for an option to download buildinfo object which was published as part of the previous build stage, and append it to the current stage build object so that we can maintain an aggregated buildinfo of the multi-branch pipeline.

Describe alternatives you've considered

No response

Additional context

No response

I want to aggregate several artifacts from Artifactory in a pipeline, including generic artifacts and conan packages. These generic artifacts show up in my buildInfo.json. However, the conan packages do not show up in the build info. What do I need to do to add the build info from conan also in the overall build info?

Describe the bug

the plugin currently only accepts global credentials that are available to all jenkins users/jobs/.. This poses a security risk as this credential can be read by any user. Instead the plugin should be able to accept a system credential which can only be accessed by jenkins administrators

Current behavior

see above

Reproduction steps

No response

Expected behavior

No response

JFrog plugin version

1.5.0

JFrog CLI version

2.56.1

Operating system type and version

linux

JFrog Artifactory version

No response

JFrog Xray version

No response

How can we help?

I run jf pip download XY in my pipeline and the packages are also downloaded correctly. However, the packages (and their dependencies) do not show up in my build info, what do I need to do to make this happen?

Describe the bug

On "Manage Jenkins -> Global Tool Configuration", I have set a JFrog CLI installation to always download the latest JFrog CLI tool available on releases.jfrog.io :

I have reproduced this issue in three different Jenkins instances (same version, same plugins and same version plugins): if I export the JCasC configuration, the exported section for the aforementioned JFrog CLI installation is incorrect, because it just exports the installation name. When importing it back, the JFrog CLI installation is partially restored in Jenkins, because it has no information that it needs to use the latest version from JFrog repository, hence jobs using jf fail with the following error:
A 'jfrog' tool was not set. Using JFrog CLI from the system path.

As documented in the main page from this plugin and from #7, this is the right exported configuration for this case I have tested:

  jfrog:
    installations:
    - name: "jfrog-cli-latest"
      properties:
      - installSource:
          installers:
          - "releasesInstaller"

Current behavior

The JCasC configuration is partially exported:

  jfrog:
    installations:
    - name: "jfrog-cli-latest"

Reproduction steps

1. Install Jenkins and the following plugins: configuration-as-code and jfrog.
2. Go to "Manage Jenkins -> Global Tool Configuration"
3. Create a new JFrog CLI installation to always download the latest JFrog CLI tool available on releases.jfrog.io. A valid test name could be jfrog-cli-latest.
4. Go to "Manage Jenkins -> Configuration as Code" and click on the "View Configuration" button to export the JCasC confguration.
5. Search for the string jfrog: to see how the related configuration was exported.

Expected behavior

The JCasC configuration is correctly exported:

  jfrog:
    installations:
    - name: "jfrog-cli-latest"
      properties:
      - installSource:
          installers:
          - "releasesInstaller"

JFrog plugin version

1.4.0

JFrog CLI version

any

Operating system type and version

AmazonLinux 2

JFrog Artifactory version

No response

JFrog Xray version

No response

Describe the bug

Build info records for Jenkins jobs with special characters in the name are broken. Accessing the build info through the “Artifactory Build Info” link inside Jenkins and the Artifactory UI does not work as intended. It appears to be related to disagreements in URL encoding between the Jenkins plugin, the generated build-info file, and Artifactory.

Current behavior

I created a minimum job that published the following job-info file for testing:

{
  "version" : "1.0.1",
  "name" : "foo/bar",
  "number" : "3",
  "buildAgent" : {
	"name" : "GENERIC",
	"version" : "2.53.2"
  },
  "agent" : {
	"name" : "jenkins-jfrog-plugin",
	"version" : "1.5.0"
  },
  "started" : "2024-03-08T17:54:38.413+0000",
  "durationMillis" : 0,
  "artifactoryPrincipal" : "[email protected]",
  "url" : "https://jenkins.example.com/job/foo/job/bar/3/"
}

The record itself appears as artifactory-build-info/foo%2Fbar/3-1709920478413.json in Artifactory.

When using the info link generated by Jenkins, for example, https://artifactory.example.com/ui/builds/foo%2Fbar/3/1709920478413/published?buildRepo=artifactory-build-info, I am redirected to the Artifactory home page. My web console shows I got a 404 for the requested page before the redirect.

When I attempt to navigate to the build in the Artifactory UI (https://artifactory.example.com/ui/builds/foo%2Fbar/?buildRepo=artifactory-build-info) the page hangs and never loads.

Using the web console, I can see that it is getting a 404 trying to POST to the API (https://artifactory.example.com/ui/api/v1/global-search/builds/foo%2Fbar?jfLoader=false).

Digging into it a bit, if I manually upload a build-info file replacing the name foo/bar with foo%2Fbar it generates a artifactory-build-info/foo%252Fbar/3-1709920478413.json record that does work as intended in the Artifactory UI, with the caveat that it appears as foo%2Fbar instead of foo/bar in the build-info menu.

This appears to be related to some URL encoding disagreements between the plugin and Artifactory. I am not sure which is at fault exactly, but I would love to see a workaround or fix for this issue, as not having access to build info is also breaking things like artifact promotion.

Reproduction steps

1. create a Jenkins pipeline within a folder, or a multi-branch job ex. foo/bar
2. use the plugin to publish build info jf "rt build-publish"
3. Try and view the build info in the Artifactory UI, or use the Build Info link in Jenkins

Expected behavior

You should be able to access the build info via the Jenkins link and view it in the Artifactory UI.

JFrog plugin version

1.5.0

JFrog CLI version

2.53.2

Operating system type and version

linux, ubuntu, 22.04

JFrog Artifactory version

7.77.6

JFrog Xray version

n/a