jfrog CLI plugin v 1.5.8 again has "--password-stdin" enabled as reported in this issue - https://github.com/jenkinsci/jfrog-plugin/issues/42.

[parameswaranj]

Describe the bug

Recently updated the Jfrog Plugin on Jenkins to v 1.5.8 and it again asks the same --password-stdin as reported here - #42.

As the issue says, no issues with plugin ver 1.5.5.

Evidence in our current jenkins pipeline logs:

Executing sh script inside container python-metrics of pod build-jobs-testapp-86-97p2s-bgn1s Executing command: "/home/jenkins/agent/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf" "-v" exit jf version 2.73.2 Executing sh script inside container python-metrics of pod build-jobs-testapp-86-97p2s-bgn1s Executing command: "/home/jenkins/agent/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf" "c" "add" "jfrog-prod" "--user=jenkins" "--password-stdin" "--url=https://artifactory.xxx.com/" "--artifactory-url=https://artifactory.xxx.com/artifactory" "--distribution-url=https://artifactory.xxx.com/distribution" "--xray-url=https://artifactory.xxx.com/xray" "--interactive=false" "--overwrite=true" exit

The command continues to run until the pipeline is aborted.

Current behavior

Output of the pipeline with the JFROG_CLI_LOG_LEVEL="DEBUG" enabled.

Executing sh script inside container python-metrics of pod build-jobs-testapp-86-97p2s-bgn1s Executing command: "/home/jenkins/agent/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf" "-v" exit jf version 2.73.2 Executing sh script inside container python-metrics of pod build-jobs-testapp-86-97p2s-bgn1s Executing command: "/home/jenkins/agent/tools/io.jenkins.plugins.jfrog.JfrogInstallation/jfrog-cli/jf" "c" "add" "jfrog-prod" "--user=jenkins" **"--password-stdin"** "--url=https://artifactory.xxx.com/" "--artifactory-url=https://artifactory.xxx.com/artifactory" "--distribution-url=https://artifactory.xxx.com/distribution" "--xray-url=https://artifactory.xxx.com/xray" "--interactive=false" "--overwrite=true" exit 22:13:22 [Debug] JFrog CLI version: 2.73.2 22:13:22 [Debug] OS/Arch: linux/amd64 22:13:22 [Debug] JFrog CLI version: 2.73.2 22:13:22 [Debug] OS/Arch: linux/amd64 22:13:22 [Debug] Trace ID for JFrog Platform logs: ae2f2f439b4bdd20 22:13:22 [Debug] Trace ID for JFrog Platform logs: ae2f2f439b4bdd20

Reproduction steps

Update Jfrog plugin to 1.5.8
Test any pipeline that uses "jf c add" command from the plugin.

Expected behavior

jf c add command should use the stored credential without waiting for an input and proceed forward.

JFrog plugin version

1.5.8

JFrog CLI version

2.73.2

Operating system type and version

running on a Kubernetes pod on a docker linux container (ex, node or python)

JFrog Artifactory version

7.71.9

JFrog Xray version

No response

[parameswaranj]

Can someone acknowledge the issue reported and share any updates ?

[aviad198]

Hi, Having the same issue.

[jabkl]

Same here as well

[thomaslorentsen]

We are seeing this problem on on Kubernetes but we are seeing some pipelines fail and some work.

We have a pipeline like this which gets locked up :

pipeline {
  agent none
  stages {
    stage('Run JFrog CLI') {
      tools {
        jfrog 'jfrog-cli'
      }
      agent {
        label 'jdk21-small'
      }
      steps {
        container('jdk') {
            jf "rt build-publish"
        }
      }
    }

  }
}

However removing the container block produces a working pipeline.

Making this change will work.

     steps {
            jf "rt build-publish"
      }

So what we are seeing is that any use of the container block will result in jfrog getting stuck. So what might be the problem is that jfrog cli plugin is not compatible with the container block which is part of the kubernetes plugin.

We need this problem resolved as our agents require the use of multiple containers to build our applications.

[wlfshmn]

I'm experiencing the same issue, rolling back to 1.5.7 restored function.

kubernetes agents here too.

[aidanleuck]

We are seeing this issue when running as Kubernetes agents as well. Reverting to 1.5.7 got past the intial blocker, but now I am getting a 401 unauthorized error. I believe this is because our password has a $ character in it which is causing bash/sh to interpret it as a special character. I imagine this is why the behavior changed in the first place?

[ruZZintl]

Kubernetes agents dont have stdin - so this is driving me nuts too, trying to work around it by manually creating the config etc. to no avail. Would be helpful if we can force override the stdin password use! PLEASE.

[ruZZintl]

static final Version MIN_CLI_VERSION_PASSWORD_STDIN = new Version("2.31.3");

setting tool version to 2.31.0 works, though this may introduce security issues..

need an alternative to using stdin on kubernetes agents ..

[larsskj]

Just want to chime in and add that we've had this problem for a long time as well.

[mschwehl]

We are seeing this problem on on Kubernetes but we are seeing some pipelines fail and some work.

We have a pipeline like this which gets locked up :

pipeline {
  agent none
  stages {
    stage('Run JFrog CLI') {
      tools {
        jfrog 'jfrog-cli'
      }
      agent {
        label 'jdk21-small'
      }
      steps {
        container('jdk') {
            jf "rt build-publish"
        }
      }
    }

  }
}

However removing the container block produces a working pipeline.

Making this change will work.

     steps {
            jf "rt build-publish"
      }

So what we are seeing is that any use of the container block will result in jfrog getting stuck. So what might be the problem is that jfrog cli plugin is not compatible with the container block which is part of the kubernetes plugin.

We need this problem resolved as our agents require the use of multiple containers to build our applications.

sure that the container has the jf installed ? make a sh 'jf -v' to be sure
I use a volume-mount to map the jf in every container and therefore it can be executed in every one

[thomaslorentsen]

sure that the container has the jf installed ? make a sh 'jf -v' to be sure I use a volume-mount to map the jf in every container and therefore it can be executed in every one

The tools block should install jfrog into the container.

tools {
        jfrog 'jfrog-cli'
}

We don't have jfrog installed on any containers so we rely on it being auto installed by the plugin. In fact, it is not on the jnlp container which is what is used by default if you do not use the container block. The plugin should work regardless of what container it is being run on.

In addition to this, the jf command runs, it is the login that results in the build getting locked up because it is expecting the password to be passed in.

The problem seems to be that the JFrog plugin has some incompatibility with the container block from the Kubernetes plugin.