Example: GitHub Actions with JFrog Artifactory

This walkthrough creates a GitHub Actions workflow that authenticates JFrog CLI, checks the Artifactory connection, and publishes build information with environment and Git metadata. Use it after you complete the basic JFrog Platform setup and want a copyable first continuous integration workflow.

Prerequisites

Complete the first.

You need:

A GitHub repository
A JFrog Platform URL
Either a JFrog access token or a configured OIDC integration
Permission to publish build information
Package repositories with a matching package type and deploy permission, if you extend the workflow to upload artifacts
The same build name and number on collect, upload, and publish

Before You Begin

This walkthrough assumes the model in . For more information about first-success failures such as an expired token or duplicate VCS entries, see the .

Walkthrough: Access-Token Authentication

To authenticate JFrog CLI with an access token and publish build information:

1. Add GitHub Configuration

In the GitHub repository settings, add:

Variable JF_URL: your JFrog Platform URL, such as https://acme.jfrog.io.
Secret JF_ACCESS_TOKEN: an access token with only the permissions the workflow needs.

2. Add the Workflow

Create .github/workflows/jfrog-build.yml:

name: JFrog build example

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out source
        uses: actions/checkout@v4

      - name: Set up JFrog CLI
        uses: jfrog/setup-jfrog-cli@v4
        env:
          JF_URL: ${{ vars.JF_URL }}
          JF_ACCESS_TOKEN: ${{ secrets.JF_ACCESS_TOKEN }}

      - name: Verify Artifactory
        run: jf rt ping

      - name: Add build metadata
        run: |
          jf rt bce
          jf rt bag
          jf rt bp

The Setup JFrog CLI action sets the build name and number from the workflow name and GitHub run number, so these commands can omit explicit arguments. For more information, see the access-token source example.

3. Push and Inspect the Run

Commit and push the workflow. The connection step should print:

OK

jf rt bce collects environment metadata, jf rt bag adds the Git revision and remote, and jf rt bp publishes the build information.

What You Should See in Artifactory

To confirm the published build information:

In the JFrog Platform UI, go to Builds.
Find JFrog build example and select the number matching the GitHub run.
Confirm that the build includes VCS details and environment metadata.

This generic workflow publishes build metadata. It does not upload an artifact until you add a package or upload command.

Add Artifact Publication

Choose the command that matches your project and existing Artifactory repositories.

Maven

Configure Maven repositories once with jf mvnc, then use Maven's deploy lifecycle:

- name: Build and deploy Maven package
  run: jf mvn clean deploy

Do not use clean install when the goal is remote deployment. The install goal writes to the runner's local Maven repository.

Generic Files

For a generated file:

- name: Upload output
  run: jf rt upload "dist/*" "<generic-local-repository>/my-app/${{ github.run_number }}/"

Where:

<generic-local-repository>: The name of an existing generic local repository in Artifactory

The upload is associated with the action-provided build name and number.

OIDC Variant

To avoid storing JF_ACCESS_TOKEN, configure a JFrog OIDC integration and identity mapping. Then replace the setup with:

permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: jfrog/setup-jfrog-cli@v4
        env:
          JF_URL: ${{ vars.JF_URL }}
        with:
          oidc-provider-name: setup-jfrog-cli
      - run: jf rt ping

The provider name must exactly match the JFrog integration. Keep the remaining build steps unchanged. For more information, see the OIDC source example.

Troubleshooting

The following table lists common first-run problems and their resolutions.

Problem	Resolution
`jf rt ping` returns 401 after earlier successful runs	The stored access token may have expired. Rotate the GitHub secret, or use OIDC so the workflow receives a short-lived token for each run.
OIDC token request fails	Add `id-token: write`. Check the provider name and the mapped claims.
Build appears without artifacts	Add a build-aware package command or `jf rt upload` before `bp`.
Maven package is not in Artifactory	Use `jf mvn ... deploy`, not only `install`, and configure deploy repositories.
Build metadata contains unwanted environment names	Keep CLI secret exclusions and narrow collection in sensitive environments.
Build is published twice	Let the action auto-publish or call `bp` explicitly, not both for separate revisions.
Build information contains duplicate VCS entries	Do not run `bag` alone and then rely on automatic post-step publication. The post-step also collects Git metadata. Use the complete `bce` + `bag` + `bp` sequence from the workflow example, or leave metadata and publication to the action.