jfrog/setup-jfrog-cli

Using jfrog/setup-jfrog-cli without internet access

samsmithnz opened this issue · 7 comments

samsmithnz commented

Is your feature request related to a problem? Please describe.
We have noticed that this action calls out to the internet to download the latest cli files. We use GitHub Enterprise Server, and due to company restrictions, we cannot access the internet from our action, therefore this action is currently a problem for us. Here’s an example of where the remote url to download the jfrog cli is hardcoded.

https://github.com/jfrog/setup-jfrog-cli/blob/master/src/utils.ts

image

Describe the solution you'd like to see
Can we add a parameter to specify the location (internal) to download the CLI? For example:

- uses: jfrog/setup-jfrog-cli@v2
  with:
    - path: https://internallocation.mycompany.com/jfrog-cli

Describe alternatives you've considered
One alternative is to fork and make the change ourselves, but we'd prefer to use the public action. We suspect there are others with similar requirements who would benefit from this.

yahavi commented

Hi @samsmithnz, thanks for requesting this feature! 🚀

We had a team conversation about it and we think that the solution should be a bit different - instead of providing a full URL, provide a name of a remote generic repository in Artifactory pointing to https://releases.jfrog.io/artifactory/jfrog-cli/. For example:

- uses: jfrog/setup-jfrog-cli@v2
  with:
    repo: jfrog-cli-remote

This suggested solution is similar to the one used in the JFrog Azure DevOps extension: https://www.jfrog.com/confluence/display/JFROG/JFrog+Azure+DevOps+Extension#JFrogAzureDevOpsExtension-JFrogToolsInstaller

We will add this feature to our plan and will keep you updated.
Please let me know what do you think.

  • 👍1
Deleted user commented

Hi @yahavi ,

That looks like a good solution, and would work our firmwide Artifactory instance.

  • 👍2
yahavi commented

@samsmithnz @croydondiasms,
Setup JFrog CLI 2.3.0 is released. This release includes the download-repository input:

- uses: jfrog/setup-jfrog-cli@v2
  with:
    # jfrog-cli-remote is a generic remote repository in your Artifactory pointing to https://releases.jfrog.io/artifactory/jfrog-cli/
    download-repository: jfrog-cli-remote

Read more about this feature here: https://github.com/jfrog/setup-jfrog-cli#downloading-jfrog-cli-from-jfrog-artifactory.

We'd appreciate your feedback on that.

Deleted user commented

Hi @yahavi ,

Apologies, but I had misread the earlier suggestion.
So now we have the ability to set a different remote repo (via the download-repository) . That's great!

We'd also like the ability to override the default host (releases.jfrog.io) from when the jfrog cli binary is pulled in, to our privately hosted Artifactory instance.

- uses: jfrog/setup-jfrog-cli@v2
  with:
    # jfrog-cli-remote is a generic remote repository in your Artifactory pointing to https://releases.jfrog.io/artifactory/jfrog-cli/
    download-repository: jfrog-cli-remote
    # Replace https://releases.jfrog.io/ with https://company-specific-id.jfrog.io/
    remote: company-specific-id.jfrog.io

Our runners run in a secure environment and don't have access to public urls on the internet like https://releases.jfrog.io/*

yahavi commented

@croydondiasms, thanks for your feedback.

Obviously, the runners can't access https://releases.jfrog.io, but AFAIK the recommended configuration in this situation is to whitelist external trusted sources of dependencies to the local Artifactory - Runners download from https://company-specific-id.jfrog.io/artifactory/jfrog-cli-remote which in turn acts as a proxy to https://releases.jfrog.io/artifactory/jfrog-cli:

Runner

↓ download CLI from ↓

https://company-specific-id.jfrog.io/artifactory/jfrog-cli-remote

↓ download CLI from ↓

releases.jfrog.io

If there is no choice and your Artifactory is completely isolated from the world, you can use the download-repository as a local repository or as a remote repository to your second Artifactory. For example create a local generic repository named jfrog-cli and upload the CLI binary to the following path: https://one-of-the-artifactories.jfrog.io/artifactory/jfrog-cli/v2/2.15.0/jfrog-cli-linux-amd64/jfrog:

Another option is to export 2 JFrog environments, such as the first one (alphabetically) will be the one to download the CLI from:

- uses: jfrog/setup-jfrog-cli@v2
  env:
    # The environment to download the JFrog CLI:
    JF_ENV_1: ${{ secrets.JF_SECRET_ENV_1 }}
    # The working environment:
    JF_ENV_2: ${{ secrets.JF_SECRET_ENV_2 }}
  with:
    download-repository: jfrog-cli-remote
- run: |
    # Set the JFrog configuration to use by providing the server ID (configured by the 'jf c add' command).
    jf c use local-2
    # Ping local-2 Artifactory server
    jf rt ping

Please let me know if that helped.

Deleted user commented

AFAIK the recommended configuration in this situation is to whitelist external trusted sources of dependencies to the local Artifactory - Runners

Unfortuantely we won't be able to do that due to security concerns.

The second option that you've listed would work, but it adds a lot of complexity for our end users when trying to just install the jfrog cli. If we could allow overriding the default remote (remote: company-specific-id.jfrog.io) that would be a clean way for end users to consume the jfrog binary without adding too much complexity in the actions yaml.

yahavi commented

@croydondiasms,
Thanks for your important feedback.

Please understand that we decided to not override the download URL for several reasons - Complexity is one of them - From the end user's perspective, it is easier to add only one argument, instead of duplicating the remote URL in many workflow files.
Other reasons for using a remote repository are -

  • Authentication - using the same credentials as the JFrog environment
  • Single access to the world - use only 1 artifactory to download dependencies, (only 1 JFrog environment to manage in your workflows)
  • Speed - the CLI will be cached in your local Artifactory
  • More ....

Your remote URL implies that it is a remote Artifactory server, therefore you can use it as a remote repository for your second Artifactory server which contains the JFrog binary.
Do you see any blocker for using this configuration?