OIDC-only mode that doesn’t install jfrog CLI

[pavelzw]

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

We are using this action to authenticate with OIDC to jfrog’s servers.
We don’t use jfrogs cli tools but our own tooling (docker, conda, pixi, …)
Would it be possible to skip the download + configure cli parts and only do the OIDC auth in this action and skip all of the additional jf setup?

Describe the solution you'd like to see

- uses: jfrog/setup-jfrog-cli@v4
  id: artifactory
  with:
    oidc-provider-name: ${{ vars.ARTIFACTORY_OIDC_PROVIDER }}
    oidc-audience: ${{ vars.ARTIFACTORY_OIDC_AUDIENCE }}
    oidc-only: true
  env:
    JF_URL: ${{ vars.ARTIFACTORY_URL }}
- uses: prefix-dev/[email protected]
  with:
    auth-host: ${{ vars.ARTIFACTORY_URL }}
    auth-username: ${{ steps.artifactory.outputs.oidc-user }}
    auth-password: ${{ steps.artifactory.outputs.oidc-token }}

Describe alternatives you've considered

No response

Additional context

No response

[EyalDelarea]

Hi @pavelzw,

Thank you for opening this issue!

It seems like this could potentially be achieved by exporting the environment variables, which you could reference in the rest of your workflow.

Could you please elaborate on why you need this feature? Understanding your use case will help us improve and better address your needs.

Looking forward to your insights!

[pavelzw]

Hi @EyalDelarea,

my use case is that I am only interested in authenticating to Artifactory using OIDC but I'm not using the jfrog CLI.
The additional setup steps from jfrog/setup-jfrog-cli are unnecessary in my use case and just create additional noise:

For example, this warning here:

Or these environment variables that pop up in every subsequent step:

Additionally, in corporate environments you might not have access to the internet and thus the download of https://releases.jfrog.io/artifactory/jfrog-cli/v2/2.72.5/jfrog-cli-linux-amd64/jfrog would get stuck/fail.
If you are only interested in the OIDC part and ship your own tools, this makes this action unusable.

---

this could potentially be achieved by exporting the environment variables, which you could reference in the rest of your workflow

We already export the variables in steps.artifactory.outputs.oidc-user and steps.artifactory.outputs.oidc-token, why would we need to export them as environment variables?
Exporting them as environment variables seems like an unnecessary attack vector: if you only export them as outputs, the user can decide which subsequent workflow to provide them to.
Exporting them as env variables for every step leads to every tool in your workflow being able to read these variables even though they might not need them.

[noamshemesh]

Hi @pavelzw, have you considered using the General snippet that is provided in the JFrog Platform? It is implemented with REST API without JFrog cli.