JFrog Setup CLI Bitbucket Pipe

The JFrog Setup CLI pipe copies a setup script into a Bitbucket Pipelines step. When you source that script, it downloads JFrog CLI, configures authentication, and exports build metadata so later lines can run jf commands.

The pipe does not build, upload, scan, or publish build-info by itself. Those actions happen in the jf commands you add after source.

Prerequisites

• A Bitbucket Cloud repository with Pipelines enabled.
• A JFrog Platform URL.
• Either of the following:
  • A Config Token stored in a secured JF_ENV_* variable.
  • A JFrog OIDC integration and a Bitbucket step with oidc: true.
• Network access to https://install-cli.jfrog.io.
• Package tools required by commands you run after setup.
• A local repository of the matching package type, deploy plus publish-build-info permission, and the same build name and number on later jf commands.

Before You Begin

The pipe only installs JFrog CLI. You still publish artifacts and build-info in later lines. For more information, see How Build Integration Works and Choose Plugin, CLI, or CI Wrapper.

Pipe 2.2.0 always downloads JFrog CLI from https://install-cli.jfrog.io. It has no private mirror setting.

Quick Start With a Config Token

Create the Config Token

On a trusted machine:

jf config add
jf config export <SERVER_ID>

Where:

• <SERVER_ID>: The ID of the JFrog CLI server configuration to export

For example:

jf config add
jf config export my-jfrog-server

Store the complete output from jf config export as a secured Bitbucket repository or workspace variable. Name the variable with the JF_ENV_ prefix, such as JF_ENV_PROD. Do not encode the token again.

Add the Pipe

pipelines:
  default:
    - step:
        name: Verify JFrog connection
        script:
          - pipe: jfrog/jfrog-setup-cli:2.2.0
          - source ./jfrog-setup-cli.sh
          - jf rt ping

Expected result: the sourced script installs JFrog CLI, imports every JF_ENV_* and JF_ARTIFACTORY_* Config Token, removes the setup script, and jf rt ping reports a successful Artifactory connection.

Authenticate With OpenID Connect

OIDC support starts in pipe 2.2.0 and requires JFrog CLI 2.75.0 or later. Pipe 2.2.0 defaults to CLI 2.56.1, so you must override the CLI version for OIDC.

Configure JFrog

To configure a JFrog OIDC integration for Bitbucket Pipelines:

1. In Bitbucket repository settings, open the OpenID Connect page and copy the provider URL and the repository and workspace identifiers.
2. In JFrog Access, create a Generic OpenID Connect integration.
3. Add identity mappings for the Bitbucket claims you trust.
4. Copy the JFrog OIDC provider name.

Configure the Pipeline

pipelines:
  default:
    - step:
        name: Verify JFrog with OIDC
        oidc: true
        script:
          - pipe: jfrog/jfrog-setup-cli:2.2.0
          - export JFROG_CLI_VERSION="2.75.0"
          - export JF_URL="https://<JFROG_PLATFORM_HOST>"
          - export JF_OIDC_PROVIDER_NAME="<OIDC_PROVIDER_NAME>"
          - source ./jfrog-setup-cli.sh
          - jf rt ping

Where:

• <JFROG_PLATFORM_HOST>: Host name of your JFrog Platform
• <OIDC_PROVIDER_NAME>: Name of the JFrog OIDC integration you created

Optional values:

- export JF_OIDC_AUDIENCE="<AUDIENCE>"
- export JF_CUSTOM_SERVER_ID="<SERVER_ID>"

Where:

• <AUDIENCE>: Audience value requested for the OIDC token
• <SERVER_ID>: JFrog CLI server ID to use instead of the default

The default OIDC server ID is jfrog-setup-cli-server. The script configures JFrog CLI with provider type GenericOidc and the Bitbucket step token.

How the Pipe Works

1. The pipe image copies jfrog-setup-cli.sh into the step workspace.
2. source ./jfrog-setup-cli.sh downloads JFrog CLI.
3. If OIDC variables are present, the script adds an OIDC server configuration.
4. The script imports all JF_ENV_* and JF_ARTIFACTORY_* Config Tokens.
5. It exports build name, number, URL, and a Bitbucket user agent.
6. It removes ./jfrog-setup-cli.sh.
7. Later lines in the same step run jf.

Use jf, not the deprecated jfrog command. The script defines alias jfrog=jf, but non-interactive shells do not reliably expand aliases.

Configuration Reference

The following table lists the variables the setup script reads. For definitions of build-info terms, see Build Integration Glossary.

If you import multiple servers, run jf config use <SERVER_ID> before commands that must target a specific server.

Publish Generic Artifacts and Build Information

Replace repository names with repositories from your JFrog Platform:

script:
  - pipe: jfrog/jfrog-setup-cli:2.2.0
  - source ./jfrog-setup-cli.sh
  - printf "hello from Bitbucket\n" > artifact.txt
  - jf rt u artifact.txt <GENERIC_LOCAL_REPO>/
  - jf rt bce
  - jf rt bp

Where:

• <GENERIC_LOCAL_REPO>: Target generic local repository in Artifactory

jf rt bp publishes the build name and number exported by the setup script. Without that command, the pipe does not create a build run. For more information about the record these commands publish, see About Build Info.

What You Should See Next

Open Builds in Artifactory. Find the build named:

<WORKSPACE_OWNER>-<REPOSITORY_SLUG>-<BRANCH>

Where:

• <WORKSPACE_OWNER>: Bitbucket workspace owner
• <REPOSITORY_SLUG>: Bitbucket repository slug
• <BRANCH>: Bitbucket branch name

The run number should match BITBUCKET_BUILD_NUMBER. Confirm the uploaded artifact and captured environment before adding scan or promotion commands.

Maven Example

script:
  - pipe: jfrog/jfrog-setup-cli:2.2.0
  - source ./jfrog-setup-cli.sh
  - jf mvn-config --server-id-resolve=<SERVER_ID> --repo-resolve-releases=<RELEASES_VIRTUAL> --repo-resolve-snapshots=<SNAPSHOTS_VIRTUAL> --server-id-deploy=<SERVER_ID> --repo-deploy-releases=<RELEASES_LOCAL> --repo-deploy-snapshots=<SNAPSHOTS_LOCAL>
  - jf mvn clean deploy
  - jf rt bce
  - jf rt bp

Where:

• <SERVER_ID>: JFrog CLI server ID configured by the setup script
• <RELEASES_VIRTUAL>: Virtual repository used to resolve release dependencies
• <SNAPSHOTS_VIRTUAL>: Virtual repository used to resolve snapshot dependencies
• <RELEASES_LOCAL>: Local repository used to deploy releases
• <SNAPSHOTS_LOCAL>: Local repository used to deploy snapshots

Add jf rt bag --config=./issues-collection.yml before publish only when the configuration file exists and you intend to collect issues. Run jf bs after a successful publish to scan the build, and jf rt bpr <TARGET_REPO> only after validating promotion permissions.

Gradle Example

script:
  - pipe: jfrog/jfrog-setup-cli:2.2.0
  - source ./jfrog-setup-cli.sh
  - jf gradle-config --server-id-resolve=<SERVER_ID> --repo-resolve=<RESOLVE_REPO> --server-id-deploy=<SERVER_ID> --repo-deploy=<DEPLOY_REPO>
  - jf gradle clean build
  - jf rt bce
  - jf rt bp

Where:

• <SERVER_ID>: JFrog CLI server ID configured by the setup script
• <RESOLVE_REPO>: Repository used to resolve dependencies
• <DEPLOY_REPO>: Repository used to deploy packages

The npm, Go, NuGet, and pip examples use the same placeholders.

npm Example

script:
  - pipe: jfrog/jfrog-setup-cli:2.2.0
  - source ./jfrog-setup-cli.sh
  - jf npm-config --server-id-resolve=<SERVER_ID> --repo-resolve=<RESOLVE_REPO> --server-id-deploy=<SERVER_ID> --repo-deploy=<DEPLOY_REPO>
  - jf npm ci
  - jf npm publish
  - jf rt bce
  - jf rt bp

Go Example

script:
  - pipe: jfrog/jfrog-setup-cli:2.2.0
  - source ./jfrog-setup-cli.sh
  - jf go-config --server-id-resolve=<SERVER_ID> --repo-resolve=<RESOLVE_REPO> --server-id-deploy=<SERVER_ID> --repo-deploy=<DEPLOY_REPO>
  - jf go build
  - jf go-publish <MODULE_VERSION>
  - jf rt bce
  - jf rt bp

Where:

• <MODULE_VERSION>: Version of the Go module to publish

NuGet and pip Examples

NuGet restore:

- jf nuget-config --server-id-resolve=<SERVER_ID> --repo-resolve=<RESOLVE_REPO>
- jf nuget restore
- jf rt bce
- jf rt bp

pip install:

- jf pip-config --server-id-resolve=<SERVER_ID> --repo-resolve=<RESOLVE_REPO> --server-id-deploy=<SERVER_ID> --repo-deploy=<DEPLOY_REPO>
- jf pip install -r requirements.txt
- jf rt bce
- jf rt bp

Docker Example

- jf docker login
- jf docker pull <REGISTRY>/<IMAGE>:<TAG>
- jf docker push <REGISTRY>/<IMAGE>:<TAG>
- jf rt bce
- jf rt bp

Where:

• <REGISTRY>: Docker registry host name for your Artifactory Docker repository
• <IMAGE>: Image name
• <TAG>: Image tag

The Bitbucket runner must provide a working Docker daemon and network access to the Artifactory registry.

Air-Gapped Runners, Proxies, and Certificates

Pipe 2.2.0 runs:

curl -fL https://install-cli.jfrog.io | sh

Therefore:

• An air-gapped runner cannot use this pipe unless it can reach that endpoint.
• Set HTTP_PROXY, HTTPS_PROXY, and NO_PROXY on the step when required.
• Install custom certificate authorities in the runner or container trust store.
• The pipe does not install custom CAs or expose an installer mirror variable.

Troubleshooting

The following table lists common problems and their resolutions.

Frequently Asked Questions

This section provides answers to frequently asked questions.

Related Topics

• Build Integration FAQ
• JFrog Build Offerings by Package Type
• Build-Info Repository
• Inspect Builds
• Manage Builds