Build Integration

Choose a JFrog build integration and publish artifacts and build-info to Artifactory.

Build Integration is the set of JFrog plugins, CLI workflows, and CI wrappers that connect a job to Artifactory. Use this hub to learn the model, pick a current path, then publish artifacts and build-info so you can inspect the run later.

A complete job produces three outcomes under one build name and number: resolve from Artifactory when you use it as a source, deploy artifacts to the matching repository type, and publish one build-info record. Artifacts without build-info, or build-info without artifacts, are incomplete.

Why You Do This

Artifacts in a repository answer what was produced. Build-info answers which job, tools, modules, dependencies, and source produced it. Inspection, promotion, retention, and build-scoped search depend on that record.

Use this path when the same CI run must be findable later under Artifactory > Builds, with modules linked to artifacts. Skip it if you only need an ad-hoc file copy with no build identity.

Before You Begin

  • A JFrog Platform URL you can reach from the build agent.
  • At least one local Artifactory repository of the package type you will publish (Maven, Gradle, generic, and so on).
  • An identity that can deploy artifacts and publish build-info.
  • A CI secret store, or equivalent, for tokens. Do not commit credentials.

If the job already uses an older Artifactory CI or Gradle 4 or Ivy integration, skip the chooser and open Legacy Plugins. Those pages are migration references, not start-here paths.

How It Works

A complete job does three things under one build name and one build number:

  1. Resolve dependencies from Artifactory (when the workflow uses Artifactory as a source).
  2. Deploy or upload artifacts to an Artifactory repository of the matching package type.
  3. Publish a build-info record so Artifactory can list the run and its modules.
flowchart LR
  job[CI_or_build_job]
  arts[Artifact_repositories]
  bi[artifactory-build-info]
  job -->|resolve_and_deploy| arts
  job -->|publish_build_info| bi
  bi -->|inspect_and_manage| ui[Artifactory_Builds_UI]

Three Layers

These layers compose. Mixing collection or publish steps across layers without a plan can duplicate Git metadata or skip environment data.

LayerWhat it isExamples
Package publisherCollects module, artifact, and dependency data from the build toolMaven Artifactory Plugin, Artifactory Gradle Plugin, JFrog CLI package commands
JFrog CLIConfigures servers and runs jf commands, including generic upload and build-publishJFrog CLI
CI wrapperInstalls or exposes CLI (or a plugin) and often supplies build name, number, and credentialsGitHub Action, Jenkins jf step, GitLab template, Azure task, Bitbucket pipe

If Maven or Gradle already owns Artifactory configuration, start with that plugin. If CI already standardizes on jf, use CLI-centric commands. If you are on hosted CI, start with that CI wrapper, then run package or upload commands inside it.

Whatever you choose, keep one build name and number for collect, deploy, and publish. CI wrappers often set JFROG_CLI_BUILD_NAME and JFROG_CLI_BUILD_NUMBER. Package plugins use their own defaults unless you override them.

Choose Plugin, CLI, or CI Wrapper

flowchart TD
  start[Where_should_Artifactory_config_live]
  start --> mavenGradle{Maven_or_Gradle_project_owns_publish}
  mavenGradle -->|yes| plugin[Maven_or_Gradle_Artifactory_plugin]
  mavenGradle -->|no| ci{Which_CI}
  ci -->|GitHub_Actions| gha[Setup_JFrog_CLI_action]
  ci -->|Jenkins| jj[Jenkins_JFrog_Plugin_jf_step]
  ci -->|GitLab| gl[GitLab_JFrog_templates]
  ci -->|Azure_DevOps| ado[JFrog_Azure_DevOps_tasks]
  ci -->|Bitbucket_Pipelines| bb[JFrog_Setup_CLI_pipe]
  ci -->|Bamboo_or_TeamCity_or_other| cli[JFrog_CLI_in_a_script_task]
  plugin --> sameId[Use_one_build_name_and_number]
  gha --> sameId
  jj --> sameId
  gl --> sameId
  ado --> sameId
  bb --> sameId
  cli --> sameId

Do not start a new job on a legacy Artifactory CI plugin, mix jf mvn with the Maven plugin in the same job unless you designed it, or mix explicit jf rt bag with GitHub Actions automatic Git collection.

Start With Your CI System

The following table lists the recommended starting page for each CI system.

CI systemStart hereGuidance
GitHub ActionsGitHub ActionsSet up JFrog CLI, then use the end-to-end example.
JenkinsJenkins JFrog PluginUse the CLI-based plugin for new Pipeline work. Existing Artifactory Plugin jobs: legacy Jenkins.
GitLab CIGitLab Templates for JFrogInclude a JFrog template to install and configure JFrog CLI.
Azure DevOpsJFrog Azure DevOps ExtensionUse current JFrog tasks for build and artifact workflows.
Bitbucket PipelinesJFrog Setup CLI Bitbucket PipeInstall and configure JFrog CLI in a pipeline step.
BambooJFrog CLINew work: CLI in Script or Command tasks. Existing plugin jobs: Bamboo JFrog Plugin or legacy Bamboo Artifactory Plugin.
TeamCityJFrog CLINew work: CLI in build steps. Existing plugin jobs: TeamCity Artifactory Plugin. That plugin is legacy, and there is no current TeamCity JFrog plugin page.
Another CI systemJFrog CLIInstall JFrog CLI in the job and use commands for your package type.

Start With Your Build Tool

The following table lists the recommended starting page for each build tool.

Build toolStart hereResult
MavenMaven Artifactory PluginResolve dependencies, deploy artifacts, and publish build-info.
GradleArtifactory Gradle PluginDeploy Gradle publications and their build-info.
Another package typeJFrog Build Offerings by Package TypeUse JFrog CLI on the Artifactory docs. This tree does not own a second plugin for each type.

After Your First Publish

  1. Confirm the artifact in the target repository.
  2. Open Artifactory > Builds and inspect the run. Empty Environment is expected unless collection is on. For more information, see the Build Integration FAQ.
  3. Optionally append, promote, or discard after you understand the scope.
  4. Administrators: Build-Info Repository.

For a complete GitHub workflow, continue to Continuous Integration between GitHub Actions and Artifactory.

The Build Integration Glossary defines the terms used on this hub.

📘

Note

If you maintain an older Jenkins, Bamboo, VSTS, Gradle, Ivy, or TeamCity integration, use the Legacy Plugins section to find its current replacement or migration path. Do not start a new integration from the legacy pages.

Learning Resources

For hands-on practice with the commands and workflows on this hub, use the following resources.

Related Topics


Did this page help you?