Hi @mackaybeth ,
Thanks for reporting this issue.
Are you sure that you added the secrets correctly on the secrets section under <github_repo_url>/settings/secrets/actions?

JF_ENV_1: ${{ secrets.JF_SECRET_ENV_1 }}
OR

JF_URL: ${{ secrets.ARTIFACTORY_URL }}
JF_ACCESS_TOKEN: ${{ secrets.ARTIFACTORY_TOKEN }}

Can you try running an echo command to print the value of secrets.ARTIFACTORY_URL on runtime?
Also, can you add the JFROG_CLI_LOG_LEVEL="DEBUG" env to the Action and provide the full logs?
It looks like the JFrog CLI is not getting your Credentials and that's why it asks for url.

I also experience this issue in my GitHub pipelines. But it doesn't occur always. Usually after a retry it works. If I enable JFROG_CLI_LOG_LEVEL="DEBUG" I get the following output.

Run jf rt ping
13:55:15 [Debug] JFrog CLI version: 2.50.4
13:55:15 [Debug] OS/Arch: windows/amd64
13:55:15 [Debug] Locking config file to run config Clear command.
13:55:15 [Debug] Creating lock in: C:\windows\ServiceProfiles\NetworkService.jfrog\locks\config
13:55:15 [Debug] Releasing lock: C:\windows\ServiceProfiles\NetworkService.jfrog\locks\config\jfrog-cli.conf.lck.1952.1701348915532607900
13:55:15 [Debug] Config Clear command completed successfully. config file is released.
Error: 5 [Error] the --url option is mandatory

@shelling21
It looks like a race condition - the config got cleared before the JFrog CLI read it.
Could you please provide an outline of the workflow you used?

I'm curious where the race condition can take place. We use this in a pipeline that performs a hardware-in-the-loop test on a windows host which take about 3-4 minutes to complete. It looks like:

---
name: Hardware in the loop test

on:
  workflow_call:
    inputs:
      buildNumber:
        description: GitHub build number
        required: true
        type: string
      configuration:
        description: Use a Debug or Release configuration in hil test
        required: true
        type: string
      testTag:
        description: Test tag
        required: true
        type: string

permissions:
  contents: read

env:
  GIT_COMMIT: ${{ github.sha }}
  JFROG_CLI_LOG_LEVEL: DEBUG

jobs:
    steps:
      - name: Checkout repository
        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
        with:
          persist-credentials: false
          submodules: false
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Setup jfrog-cli
        uses: jfrog/setup-jfrog-cli@901bb9632db90821c2d3f076012bdeaf66598555 # v3.4.1
        env:
            JF_ENV_1: ${{ secrets.ARTIFACTORY_TOKEN }}

      - name: Download xxx tool
        run: jf rt download generic-external/xxx.exe "xxx.exe"

      - name: Download embedded builds
        env:
          JFROG_CLI_BUILD_NAME: pkgs-embedded+arm-none-eabi
        run: jf rt download --build pkgs-embedded+arm-none-eabi/${{ inputs.buildNumber }} "*/(*)/${{ inputs.configuration }}/(*)" "install/{1}/${{ inputs.configuration }}/{2}"

      - name: Download tools
        env:
          JFROG_CLI_BUILD_NAME: pkgs-embedded+i686-w64-mingw32
        run: jf rt download --build pkgs-embedded+i686-w64-mingw32/${{ inputs.buildNumber }} "*/(*)/Debug/(*)" "install/tools/{1}/Debug/{2}"

      - name: Program device 1
        run: |
          <Programming commands>

      - name: Program device 2
        run: |
          <Programming commands>

      - name: Reset test setup
        run: |
          <Reset commands>

      - name: Sleep for 3 seconds
        run: Start-Sleep -s 3
        shell: powershell

      - name: Run hardware-in-the-loop tests
        run: >
          <Run hardware-in-the-loop commands>

      - name: Upload test report
        if: success() || failure()
        env:
          DEST_PATH: pkgs-embedded-snapshot/nic/${{ github.head_ref || github.ref_name }}/${{ github.run_number }}/
          JFROG_CLI_BUILD_NAME: pkgs-embedded+smoke-test-output-${{ inputs.testTag }}
        run: |
          jf rt ping
          jf rt build-collect-env
          jf rt upload "integration_test_output/*" "${{ env.DEST_PATH }}"
          jf rt build-publish

(I removed the unrelevant parts)
Usually the process fails on the jf commands in the last step.

@yahavi : I'm really curious what the problem can be and how to resolve it. Currently our CI/CD pipeline is unstable because of this issue and I would like to fix that.

Hi @shelling21 and @mackaybeth,
We believe that the issue was fixed on https://github.com/jfrog/setup-jfrog-cli/releases/tag/v3.4.2 so feel free to update to the latest version.
Looking forward to your feedback on it.

Hi @sverdlov93,

I've updated the setup-jfrog-cli action to v3.4.2 but it does not seem to resolve the issue. The same issue happens. The problem seems to be most likely to trigger when there is a longer time between the setup-jfrog-cli action and actually using the jf command in later steps. In our use case we're downloading some binaries with the jf cli, then programming a hw target, run some tests, and then upload the test results to artifactory. Usually the failures are happening in the last upload step. It looks like some token gets expired.

For now I got a workable solution to do a setup-jfrog-cli action before each time I use jf cli. Then when the token seems to get renewed when necessary. If there is already a config with a valid token it passes the action in 0s.

Hi @shelling21 , Are you getting the same debug logs with [Debug] Config Clear command completed successfully. config file is released. that happens before your last command?
can you share again the full logs?

@sverdlov93: I've sent you the logs via e-mail (from your GitHub profile)

Hi @shelling21 , I see from your logs that you are using an old version of jfrog/setup-jfrog-cli.
The latest is v3.5.1 and it should use the version v2.52.7 of JFrog CLI.

On your logs it was:

jfrog/setup-jfrog-cli@901bb9632db90821c2d3f076012bdeaf66598555
with:
 version: 2.50.4

I'm running into this today with

- uses: jfrog/setup-jfrog-cli@v4
        with:
          version: latest

putting jf config show in the action does show a proper config

@ssplatt , how do you configure the credentials for the task?
Can you share the full yaml you use?

here is an example:

- uses: jfrog/setup-jfrog-cli@v4
  env:
    # JFrog platform url (for example: https://acme.jfrog.io)
    JF_URL: ${{ vars.JF_URL }}

    # Basic authentication credentials
    JF_USER: ${{ secrets.JF_USER }}
    JF_PASSWORD: ${{ secrets.JF_PASSWORD }}
    or
    # JFrog Platform access token
    JF_ACCESS_TOKEN: ${{ secrets.JF_ACCESS_TOKEN }}
- run: |
    jf rt ping

Jf_url and jf_access_token as env vars

is there a chance that your env URL is empty? can you add another step before the jfrog-cli step that prints ${{ vars.JF_URL }} to the prompt?

We've been having the same issue recently in enterprise at the Post Download/Upload cleanup, here down some log,

Download Artefacts from Artifactory
...
Run jfrog/setup-jfrog-cli@v4
with:
download-repository: jfrog-cli-remote
version: 2.67.0
disable-job-summary: false
disable-auto-build-publish: false
env:
product-name: product-fake
component-name: xxxxxx-service
version: 1729012922-xxxxx
archive-extension: jar
artifact-path: artefact-release
project-name: ProductService
docker-registry-source: docker.registry.com
artifactory-url: https://artifacts.server.com
artifactory-serverid: artifactory
reports-format: ALL
ARTIFACTORY_API_KEY: ***
ARTIFACTORY_USER: ***
JF_URL: https://artifacts.server.com/
JF_USER: ***
JF_PASSWORD: ***
Setup JFrog CLI
Downloading JFrog CLI from https://artifacts.artifacts.server.com/artifactory/jfrog-cli-remote/v2/2.67.0/jfrog-cli-linux-amd64/jfrog
/opt/hostedtoolcache/jf/2.67.0/x64/jf config add setup-jfrog-cli-server --url https://artifacts.artifacts.server.com/ --interactive=false --overwrite=true --user *** --password ***
[Warn] You are using JFrog CLI version 2.67.0, however version 2.71.1 is available.
To install the latest version, visit: https://jfrog.com/getcli
To see the release notes, visit: https://github.com/jfrog/jfrog-cli/releases
To avoid this message, set the JFROG_CLI_AVOID_NEW_VERSION_WARNING variable to TRUE
...

Post Download Artefacts from Artifactory
Post job cleanup.
Post job cleanup.
Checking connection to JFrog Artifactory
/opt/hostedtoolcache/jf/2.67.0/x64/jf rt ping
(https://github.com/Enterprise/xxxxxx-service/actions/runs/11521703694/job/32075950521#step:9:3):31 [Info] Trace ID for JFrog Platform logs: 4f3268f7c9abd8e7
Error: 1 [Error] the --url option is mandatory
Warning: An error occurred while trying to connect to Artifactory: Error: JFrog CLI exited with exit code 1. Skipping Build Info post tasks.
Cleanup JFrog CLI servers configuration
/opt/hostedtoolcache/jf/2.67.0/x64/jf c rm --quiet

JF_URL var is not empty at the Download step, but it seems it is empty an the Post job cleanup.

I guess it comes from this function checkConnectionToArtifactory at the cleanup.js, but we don't understand why.
https://github.com/jfrog/setup-jfrog-cli/blob/master/lib/cleanup.js#L163

function checkConnectionToArtifactory() {
    return __awaiter(this, void 0, void 0, function* () {
        try {
            core.startGroup('Checking connection to JFrog Artifactory');
            const pingResult = yield utils_1.Utils.runCliAndGetOutput(['rt', 'ping']);
            if (pingResult.trim() !== 'OK') {
                core.debug(`Ping result: ${pingResult}`);
                core.warning('Could not connect to Artifactory. Skipping Build Info post tasks.');
                return false;
            }
            return true;
        }
        catch (error) {
            core.warning(`An error occurred while trying to connect to Artifactory: ${error}. Skipping Build Info post tasks.`);
            return false;
        }
        finally {
            core.endGroup();
        }
    });
}

Thanks

Hi @alexquitiaquez, thanks for reaching out!

Quick question: is this issue causing the workflow to fail, or is it just displaying a warning?

The JF_URL and similar environment variables are not directly used by the postJob task. Instead, it relies on the server configuration set up by the setup-jfrog-cli task, which is stored locally on the runner VM during the run. It appears that the local JFrog configuration may have been removed between steps, affecting the cleanup process.

Could you share your workflow YAML file for further troubleshooting?
Could you also explain the following fields I see on your envs:

artifactory-url: https://artifacts.server.com/
artifactory-serverid: artifactory
ARTIFACTORY_API_KEY: ***
ARTIFACTORY_USER: ***

Hi @sverdlov93 ,
No, the workflow doesn't fail, we just have a warning under the Annotations section, but I think it's because the warning on the next line during the execution, not because the error message. The error message is only shown in the logs.

Error: 1 [Error] the --url option is mandatory
Warning: An error occurred while trying to connect to Artifactory: Error: JFrog CLI exited with exit code 1. Skipping Build Info post tasks.

The annoying thing is having the same warning as many times as you use the action.
In this example of a multilayer workflow, I mean a reusable workflow that uses other reusable workflows, the action is used by 5 different jobs,

Annotations
5 warnings
ci-with-gradle / build-and-test / build-and-test
An error occurred while trying to connect to Artifactory: Error: JFrog CLI exited with exit code 1. Skipping Build Info post tasks.
ci-with-gradle / deploy / deploy
An error occurred while trying to connect to Artifactory: Error: JFrog CLI exited with exit code 1. Skipping Build Info post tasks.
ci-with-gradle / smoke-test / smoke-test
An error occurred while trying to connect to Artifactory: Error: JFrog CLI exited with exit code 1. Skipping Build Info post tasks.
ci-with-gradle / generate-lst / generate-lst
An error occurred while trying to connect to Artifactory: Error: JFrog CLI exited with exit code 1. Skipping Build Info post tasks.
ci-with-gradle / static-analysis / static-analysis
An error occurred while trying to connect to Artifactory: Error: JFrog CLI exited with exit code 1. Skipping Build Info post tasks.

Sorry, I can't share images of my corporate environment.

About your other questions,

1. Could you share your workflow YAML file for further troubleshooting?
   We have an internal composite action wrapping the setup-jfrog-cli, we can call it here wrapper-jfrog-cli-action it receives values through inputs, here below the main parts of the action.yml,

name: "Upload|Download file(s) to|from Artifactory and/or Docker_Pull|Build_Docker_Create|Build_Publish|Docker_Promote Docker image and/or build_scan and/or bundle_create|bundle_Promote Release Bundle"
description: "Artifactory"
inputs:
  local-file-path:
    required: false
    description: "Local file pattern"
  destination-file-path:
    required: false
    description: "Destination file pattern"
  artifactory-action:
    required: true
    description: "upload, download or docker_promote"
  artifactory-serverid:
    required: false
    description: "Serverid du serveur Artifactory"
    default: "artifactory"
  jfrog-args:
    required: false
    description: "additional arguments for the Jfrog CLI, see [Welcome to JFrog CLI](https://www.jfrog.com/confluence/display/CLI/JFrog+CLI)"
  artifactory-user:
    required: true
    description: "Secret: username for Artifactory server."
  artifactory-api-key:
    required: true
    description: "Secret: artifactory-api-key for API Artifactory"
  artifactory-url:
    required: false
    description: "URL Artifactory server"
    default: "https://artifacts.server.com"
  search-artifacts-before-upload:
    required: false
    description: "Look for the artefacts before uploading them"
    default: "false"
...

outputs:
  local-file-path:
    description: "Local file pattern"
    value: ${{ steps.jfrog.outputs.local-file-path }}
  destination-file-path:
    description: "Destination file pattern"
    value: ${{ steps.jfrog.outputs.destination-file-path }}

runs:
  using: "composite"
  steps:
    - name: Setup JFrog CLI
      uses: jfrog/setup-jfrog-cli@v4
      env:
        JF_URL: ${{ inputs.artifactory-url }}
        JF_USER: ${{ inputs.artifactory-user }}
        JF_PASSWORD: ${{ inputs.artifactory-api-key }}
      with:
        download-repository: jfrog-cli-remote
...

In a workflow, this wrapper-jfrog-cli-action is called as follows,

      - name: Download artifact from Artifactory
        # Downloading artifact to be deployed
        id: artifacts-download
        uses: Corpo/wrapper-jfrog-cli-action@v1
        with:
          local-file-path: ${{ inputs.artifact-path }}/
          destination-file-path: ${{ inputs.artifactory-repo }}/${{ steps.group-id-to-path.outputs.group-id-path }}/${{ inputs.component-name }}/${{ inputs.build-version }}/${{ inputs.component-name }}-${{ inputs.build-version }}.${{inputs.archive-extension}}
          artifactory-action: download
          artifactory-serverid: ${{inputs.artifactory-serverid}}
          jfrog-args: --flat=true
          artifactory-user: ${{ steps.secrets.outputs.ARTIFACTORY_USER }}
          artifactory-api-key: ${{ steps.secrets.outputs.ARTIFACTORY_API_KEY }}
          artifactory-url: ${{ inputs.artifactory-url }}

2. Could you also explain the following fields I see on your envs:
   It just because in my reduced and simpler version of an example workflow, I used environment variables at the top level of my example workflow in order to share the values through the whole workflow, but these values are usually taken from inputs:

name: Example workflow

on:
  workflow_dispatch:
    inputs:
      version:
        description: Application version to be deployed
        required: true
        default: '1729058922-fdsf344'

env:
  product-name: ${{ github.event.repository.custom_properties.product }}
  component-name: xxxxxx-service
  version: ${{ inputs.version }}
  archive-extension: jar
  # Artifactory
  artifact-path: artefact-release
  project-name: ProductService
  artifactory-url: https://artifacts.server.com/
  artifactory-serverid: artifactory
  reports-format: ALL

jobs:
  dependency-check:
    runs-on: ${{ inputs.runs-on || vars.DEFAULT_RUNNER_LABEL }}
    steps:
      - uses: actions/checkout@v4
      - name: Import Secrets
        id: secrets
        uses: xxx-action-for-secrets
        with:
          secrets: |
            concourse/${{ env.product-name }}/artifactory-api-key value | ARTIFACTORY_API_KEY ;
            concourse/${{ env.product-name }}/artifactory-user value | ARTIFACTORY_USER ;

      - name: Download Artefacts from Artifactory
        id: artifacts-download
        uses: Corpo/wrapper-jfrog-cli-action
        with:
          local-file-path: ${{ env.artifact-path }}/
          destination-file-path: release-local/com/${{ env.product-name }}/${{ env.component-name }}/${{ env.version }}/${{ env.component-name }}-${{ env.version }}.${{ env.archive-extension }}
          artifactory-action: download
          artifactory-serverid: ${{env.artifactory-serverid}}
          jfrog-args: --flat=true
          artifactory-user: ${{ env.ARTIFACTORY_USER }}
          artifactory-api-key: ${{ env.ARTIFACTORY_API_KEY }}
          artifactory-url: ${{ env.artifactory-url }}

Hope it's more clear now.

Thanks

Now a quick question from my side, we are using self hosted runners, so you think there is some local JFrog configuration lost between the calling step and the cleanup process at the end, right?
Could you share whith us, where this config is saved by the action on the runner please? I guess it is under the runner's file system?
Thanks again

Hi @alexquitiaquez,

Thank you for your feedback. I understand the warnings are annoying, and they shouldn’t occur in the first place. I just wanted to clarify that these warnings are not causing the workflows to fail, which is the intended behavior.

I suspect the issue may be related to the self-hosted runner. The JFrog CLI configuration is stored in the <user home dir>/.jfrog directory (can be also set by JFROG_CLI_HOME_DIR env).
Are you running multiple workflows concurrently on the same self-hosted runner?

No, the runner is not supposed to run more than 1 workflow at a time and runners are ephemeres (destroyed after the execution)

Hi @alexquitiaquez,

I tried to reproduce this issue using a composite action in this workflow, and it worked as expected.

Could something in your workflow setup be removing the JFrog configuration? Possible causes might include:

1.	Deleting the <userhome>/.jfrog directory at some point.
2.	Running setup-jfrog-cli more than once within the same workflow.
3.	Running `jf c rm` manually, which would remove the JFrog CLI configuration.

also, can you run jf c show in your workflow and see your configuration there?