JFrog CLI, Your GitHub Actions Hero
Now that GitHub Actions version 2 is out of Beta and available for general use, how can you start managing your Artifactory repositories in your automated DevOps workflows? Who will save your binaries in distress?
Never fear, JFrog is here! A new Action has joined the GitHub Marketplace that enables you to use the JFrog CLI in your GitHub Actions workflows to move your builds through development, test, and release.
Integrating Artifactory with automation tools you choose has always been easy through the JFrog CLI. Through this simple command line interface, you can perform all the functions you need to create a controlled DevOps path for all your software binaries.
Previously On DevOps…
GitHub first released GitHub Actions at GitHub Universe in 2018, an awesome new method of automating workflows for continuous integration (CI) and continuous deployment (CD). Through some simple scripts, you can execute any number of operations against your GitHub repository, triggered by events like a source code push. From within GitHub itself, you can run custom automated processes to build, test, package, release, or deploy any code project.
There have been a few important changes since then — the biggest with the recent release of version 2, which uses a YAML-based description language instead of the HCL used in version 1.
Developers have been keeping up though, and GitHub Marketplace offers a variety of helpful Actions for things like running a linter, deploying to AWS Lambda, or running Jest. And now using Artifactory joins that list!
To use any of these published Actions (or your own, private Actions), they must be defined within a GitHub Actions workflow in your repository. Let’s take a look at how that’s done with the new Setup JFrog CLI Action.
JFrog CLI To The Rescue
The Setup JFrog CLI Action enables you to issue any JFrog CLI command for Artifactory through the run
block in your workflow. For example:
- uses: jfrog/setup-jfrog-cli@v1 - run: jfrog --version
The Action eases things further by automatically managing the build name and build number options and arguments to the JFrog CLI commands that accept them. All build related operations will be automatically recorded with the Workflow Name as build name and Commit Hash as build number.
For example, this set of download, upload, and build info CLI commands don’t need to specify the build name and build number since they are automatically added for you:
run: | jfrog rt dl artifacts/ jfrog rt u aether artifacts/ jfrog rt bp
If you need those identifiers, they are exposed as environment variables JFROG_CLI_BUILD_NAME and JFROG_CLI_BUILD_NUMBER.
Connecting To the Artifactory Server
To work with Artifactory, however, the Action needs the token that contains the configuration details that will grant access to the Artifactory server. You should store the token inside of an encrypted secret in GitHub, where the Action can securely retrieve it during execution without exposing its details in the GitHub Actions workflow script.
To obtain the token, you’ll have to have the JFrog CLI installed on your local workstation. When you’re logged into Artifactory through your own user credentials, you can obtain the token through the JFrog CLI command:
$ jfrog rt c export
You can copy the token, create an encrypted secret in GitHub and store the token there. For example, store it as a secret named artifactory_token_1
.
The Action expects the token to be exposed as an environment variable named with the prefix JF_ARTIFACTORY_. You can assign that environment variable through the secrets
context.
- uses: jfrog/setup-jfrog-cli@v1 env: JF_ARTIFACTORY_1: ${{ secrets.artifactory_token_1 }} - run: | # Ping the server jfrog rt ping
Artifactory Saves the Day
You can learn more about the Setup JFrog CLI Action, including how to work with multiple Artifactory servers, in the README file in the Setup JFrog CLI Action GitHub Repo.
We think you’ll find this action pretty helpful for automating your use of Artifactory in GitHub Action workflows, and easy to use. But if you can think of improvements, we’re delighted to include them. As always, we welcome changes through pull requests, and would love to see it improved!