Giter VIP home page Giter VIP logo

jfrog-plugin's Introduction

Jenkins JFrog Plugin

Scanned by Frogbot Tests Static Analysis

Table of Contents

Overview

The Jenkins JFrog Plugin allows for easy integration between Jenkins and the JFrog Platform. This integration allows your build jobs to deploy artifacts and resolve dependencies to and from Artifactory, and then have them linked to the build job that created them. It also allows you to scan your artifacts and builds with JFrog Xray and distribute your software package to remote locations using JFrog Distribution. This is all achieved by the plugin by wrapping JFrog CLI. Any JFrog CLI command can be executed from within your Jenkins Pipeline job using the JFrog Plugin.

Installing and configuring the plugin

  1. Install the JFrog Plugin by going to Manage Jenkins | Manage Plugins.
  2. Configure your JFrog Platform details by going to Manage Jenkins | Configure System.
  3. Configure JFrog CLI as a tool in Jenkins as described in the Configuring JFrog CLI as a tool section.

Configuring JFrog CLI as a tool

General

To use JFrog CLI in your pipelines jobs, you should configure it as a tool in Jenkins by going to Manage Jenkins | Global Tool Configuration. You can use one of the following installation options:

Automatic installation from release.jfrog.io

If your agent has access to the internet, you can set the installer to automatically download JFrog CLI from https://releases.jfrog.io as shown in the below screenshot.

Automatic installation from Artifactory

If your agent cannot access the internet, you can set the installer to automatically download JFrog CLI from the JFrog instance you configured in Manage Jenkins | Configure System as shown in the below screenshot. To set this up, follow these steps:

  1. Create a generic remote repository in Artifactory for downloading JFrog CLI. You can name the repository jfrog-cli-remote. This is the name we'll be using here, but you can also choose a different name for the repository. Set the repository URL to https://releases.jfrog.io/artifactory/jfrog-cli/

  2. In Manage Jenkins | Global Tool Configuration select the Install from Artifactory option as shown in the screenshot below.

  3. Set the Server ID of your JFrog instanced, which you configured in Manage Jenkins | Configure System. Also set jfrog-cli-remote as the name of the remote repository you created to download JFrog CLI from. If you used a different name for repository, set this name here.

Manual installation

Install JFrog CLI manually on your build agent, and then set the path to the directory which includes the jf executable, as shown in the below screenshot.

Using JFrog CLI in your pipeline jobs

To have your pipeline jobs run JFrog CLI commands, add the following to your pipeline script.

Step 1: Define JFrog CLI as a tool, by using the tool name you configured. For example, if you named the tool jfrog-cli, add the following to the script:

tools {
    jfrog 'jfrog-cli'
}
Scripted Pipeline
withEnv(["JFROG_BINARY_PATH=${tool 'jfrog-cli'}"]) {
    // The 'jf' tool is available in this scope.
}

Step 2: Use the jf step to execute any JFrog CLI command as follows:

// Upload all files in the target directory to the my-repo Artifactory repository.
jf 'rt u target/ my-repo/'

IMPORTANT: Notice the single quotes wrapping the command right after the jf step definition.

If the JFrog CLI command has arguments with white-spaces, you can provide the arguments as a list as follows:

jf(['mvn', 'clean', 'install', '-Ddeploy.testProperty=Property with space'])

When the above list syntax is used, the quotes required for the string syntax are replaced with quotes wrapping each item in the list as shown above. The above step is equivalent to the following shell command:

bash-spaces.png

The list syntax also helps avoiding space and escaping problems, when some of those arguments use script variables.

Setting the build name and the build number

The plugin automatically sets the following environment variables: JFROG_CLI_BUILD_NAME and JFROG_CLI_BUILD_NUMBER with Jenkins's job name and build number respectively. You therefore don't need to specify the build name and build number on any of the build related JFrog CLI commands. If you wish to change the default values, add the following code to your pipeline script:

environment {
    JFROG_CLI_BUILD_NAME = "my-build-name"
    JFROG_CLI_BUILD_NUMBER = "18"
}

Using multiple JFrog Platform instances

If you have multiple JFrog Platform instances configured, you can use the –-server-id command option with the server ID you configured for the instance. For example:

jf 'rt u test-file my-repo –-server-id server-1'
jf 'rt u test-file my-repo –-server-id server-2'

Publishing and accessing the build-info

Build-info is the metadata of a build. It includes all the details about the build broken down into segments that include version history, artifacts, project modules, dependencies, and everything that was required to create the build. In short, it is a snapshot of the components used to build your application, collected by the build agent. See below how you publish the build-info from your pipeline jobs. This section should be placed inside the job after the execution of the JFrog CLI commands used for the build.

stage('Publish build info') {
    steps {
        jf 'rt build-publish'
    }
}

When the job publishes the build-info to Artifactory, you can access it by clicking on the build-info icon, next to the job run.

build-info.png

Using HTTP/S proxy

If you're using a JFrog platform that's situated behind an HTTP/S proxy, you should set up your proxy configuration under Manage Jenkins > Manage Plugins > Advanced.

To exclude the JFrog platform from going through a configured proxy, provide your JFrog platform's host details in the No Proxy Host section. This should be a list of comma-separated hosts. Notice that the JFrog CLI is typically downloaded from releases.jfrog.io. You may need to add that to your list as well.

Jenkins Configuration as Code

To configure this plugin on Jenkins Configuration as Code, add the following sections to the jenkins.yaml:

  1. Configure connection details to the JFrog platform
    unclassified:
      jFrogPlatformBuilder:
        jfrogInstances:
          - serverId: "acme"
            url: "https://acme.jfrog.io"
            artifactoryUrl: "https://acme.jfrog.io/artifactory"
            distributionUrl: "https://acme.jfrog.io/distribution"
            xrayUrl: "https://acme.jfrog.io/xray"
            credentialsConfig:
              credentialsId: "acme-secret-recipe"
  2. Add JFrog CLI tool using one of the following methods:

Examples

Uploading and downloading generic files
pipeline {
    agent any
    tools {
        jfrog 'jfrog-cli'
    }
    stages {
        stage('Testing') {
            steps {
                // Show the installed version of JFrog CLI.
                jf '-v'

                // Show the configured JFrog Platform instances.
                jf 'c show'

                // Ping Artifactory.
                jf 'rt ping'

                // Create a file and upload it to a repository named 'my-repo' in Artifactory
                sh 'touch test-file'
                jf 'rt u test-file my-repo/'

                // Publish the build-info to Artifactory.
                jf 'rt bp'

                // Download the test-file
                jf 'rt dl my-repo/test-file'
            }
        }
    }
}
Docker

Preconditions

  1. Populate 'DOCKER_REG_URL' with the Artifactory Docker registry, for example - 'acme.jfrog.io'.
  2. Use an agent with a running Docker daemon.
  3. To build the Docker image, install the "Docker Pipeline" on Jenkins.
pipeline {
    agent any
    tools {
        jfrog 'jfrog-cli'
    }
    environment {
        DOCKER_IMAGE_NAME = "$DOCKER_REG_URL/docker-local/hello-frog:1.0.0"
    }
    stages {
        stage('Clone') {
            steps {
                git branch: 'master', url: "https://github.com/jfrog/project-examples.git"
            }
        }

        stage('Build Docker image') {
            steps {
                script {
                    docker.build("$DOCKER_IMAGE_NAME", 'docker-oci-examples/docker-example')
                }
            }
        }

        stage('Scan and push image') {
            steps {
                dir('docker-oci-examples/docker-example/') {
                    // Scan Docker image for vulnerabilities
                    jf 'docker scan $DOCKER_IMAGE_NAME'

                    // Push image to Artifactory
                    jf 'docker push $DOCKER_IMAGE_NAME'
                }
            }
        }

        stage('Publish build info') {
            steps {
                jf 'rt build-publish'
            }
        }
    }
}
Maven
pipeline {
    agent any
    tools {
        jfrog 'jfrog-cli'
    }
    stages {
        stage('Clone') {
            steps {
                git branch: 'master', url: "https://github.com/jfrog/project-examples.git"
            }
        }

        stage('Exec Maven commands') {
            steps {
                dir('maven-examples/maven-example') {
                    // Configure Maven project's repositories
                    jf 'mvn-config --repo-resolve-releases libs-release --repo-resolve-snapshots libs-snapshots --repo-deploy-releases libs-release-local --repo-deploy-snapshots libs-snapshot-local'

                    // Install and publish project
                    jf 'mvn clean install'
                }
            }
        }

        stage('Publish build info') {
            steps {
                jf 'rt build-publish'
            }
        }
    }
}
Gradle
pipeline {
    agent any
    tools {
        jfrog 'jfrog-cli'
    }
    stages {
        stage('Clone') {
            steps {
                git branch: 'master', url: "https://github.com/jfrog/project-examples.git"
            }
        }

        stage('Exec Gradle commands') {
            steps {
                dir('gradle-examples/gradle-example-ci-server') {
                    // Configure Gradle project's repositories
                    jf 'gradle-config --repo-resolve libs-release --repo-deploy libs-release-local'

                    // Install and publish project
                    jf 'gradle clean artifactoryPublish'
                }
            }
        }

        stage('Publish build info') {
            steps {
                jf 'rt build-publish'
            }
        }
    }
}
npm
pipeline {
    agent any
    tools {
        jfrog 'jfrog-cli'
    }
    stages {
        stage('Clone') {
            steps {
                git branch: 'master', url: "https://github.com/jfrog/project-examples.git"
            }
        }

        stage('Exec npm commands') {
            steps {
                dir('npm-example') {
                    // Configure npm project's repositories
                    jf 'npm-config --repo-resolve npm-remote --repo-deploy npm-local'

                    // Install dependencies
                    jf 'npm install'

                    // Pack and deploy the npm package
                    jf 'npm publish'
                }
            }
        }

        stage('Publish build info') {
            steps {
                jf 'rt build-publish'
            }
        }
    }
}
Go
pipeline {
    agent any
    tools {
        jfrog 'jfrog-cli'
    }
    stages {
        stage('Clone') {
            steps {
                git branch: 'master', url: "https://github.com/jfrog/project-examples.git"
            }
        }

        stage('Exec Go commands') {
            steps {
                dir('golang-example/hello/') {
                    // Configure Go project's repositories
                    jf 'go-config --repo-resolve go-remote --repo-deploy go-local'

                    // Build the project with go and resolve the project dependencies from Artifactory
                    jf 'go build'

                    // Publish version v1.0.0 of the package to the go-local repository in Artifactory
                    jf 'go-publish v1.0.0'
                }
            }
        }

        stage('Publish build info') {
            steps {
                jf 'rt build-publish'
            }
        }
    }
}

These examples demonstrate only a fraction of the capabilities of JFrog CLI. Please refer to the JFrog CLI documentation for additional information.

Contributions

We welcome pull requests from the community. To help us improve this project, please read our Contribution guide.

jfrog-plugin's People

Contributors

attiasas avatar basil avatar ca-monteiro avatar enaess avatar eyalbe4 avatar eyaldelarea avatar gailazar300 avatar harbulot avatar nekator avatar notmyfault avatar omerzi avatar tomerm12 avatar yahavi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

jfrog-plugin's Issues

Incorrect JCasC configuration export when a JFrog CLI installation is set to "install the latest version"

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 :
2024-05-08-jenkinsci_jfrog-plugin-JCasC_error_latest

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

add BuildInfoBadgeStep

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

(short issue description)

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

jfrog plugin using access token not working

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.

Add support for downloading published Artifactory build-info object from Artifactory and append using the Jenkins-jfrog-plugin

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

proxy support breaks nodes configuration

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

Addition of no_proxy Support from Jenkins Configuration

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

Use system credential instead of global one

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

jf gradle - calls do not work with gradlew

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:

image

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

rt build-publish not handling special characters in job names

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.
Screenshot from 2024-03-08 14-10-36

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

Return stdout of command

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...

Shared artifactory credentials setup.

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

buildInfo isn't properly collected for jobs run within a docker container

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

Allow setting custom links for execution results links

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.
image

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 to include conan build info in overall build info?

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?

How to do Interactive Build Promotion Step with new API

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 jfrog-plugin supported with docker agent integration?

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.

jfrog-cli tool install fails on mac-mini

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

Include JCasC Examples

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

rtUpload appends Git environment variables to upload URL and causes HTTP 404 error

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

jf does not consider quotes when splitting the args string

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

Jenkin could not download jfrog-cli from from releases.jfrog.io

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)

Timeout fetching the jfrog-cli binary

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.