JFrog Build Offerings By Package Type
The following table shows which JFrog clients and CI integrations can collect and publish build-info for each package type. For build-info workflows that use JFrog CLI instead of JFrog Pipelines, see JFrog CI Integrations Documentation and the JFrog CLI build tools documentation.
How to read this matrix
- Rows list package types (for example, Maven, Docker, npm, Generic).
- Columns list the JFrog client or CI integration (for example, JFrog CLI, Jenkins, GitHub Actions).
- A checkmark at the intersection means that client or integration supports collecting and publishing build-info for builds that involve that package type. It does not mean the tool only uploads artifacts without build metadata.
- An empty cell means build-info is not supported for that package type through that client or integration.
- In the JFrog Pipelines column, some checkmarks link to pipeline examples for that package type.
Integration scope
The matrix reflects documented, first-class build-info support for each integration — not every way you might run a build:
| Integration type | What a checkmark means |
|---|---|
| JFrog CLI | Direct jf command support with --build-name / --build-number and jf rt build-publish. |
| JFrog Pipelines | Native pipeline step or linked pipeline example with build-info. |
| Jenkins, Bamboo, TeamCity | Dedicated plugin task or pipeline DSL API for that package type. For broader coverage, use the Jenkins JFrog Plugin or Bamboo JFrog Plugin, which wrap JFrog CLI and inherit CLI build-info support. |
| Azure DevOps | Dedicated extension task for that package type, or generic File Spec / Docker tasks where noted. |
| GitHub Actions, Bitbucket Pipelines | Established setup-jfrog-cli / Bitbucket pipe workflow for that package type. Any package type with a JFrog CLI checkmark can also be used via manual jf commands in these CI systems, even when the CI column is empty. |
JFrog CLI column
Yes — when the JFrog CLI column shows a checkmark for a package type, JFrog CLI can generate and publish build-info for that package type. How you do this depends on the package type:
| Package type | Typical JFrog CLI workflow |
|---|---|
| Generic | Upload files with jf rt u using --build-name and --build-number, optionally enrich with jf rt build-collect-env and jf rt build-add-git, then run jf rt build-publish. |
| Maven, Gradle, npm, Go, Python, Conan, and other build tools | Run the package-specific command (for example, jf mvn, jf gradle, jf npm, jf go, jf pip, jf conan) with --build-name and --build-number, then run jf rt build-publish. |
| Docker | Use jf docker build, jf docker push, or related jf docker commands with --build-name and --build-number, then run jf rt build-publish. |
| Podman | Use jf rt podman-pull or jf rt podman-push with --build-name and --build-number, then run jf rt build-publish. |
| Kaniko | After Kaniko builds and pushes the image, run jf rt build-docker-create (jf rt bdc) with --image-file, --build-name, and --build-number, then run jf rt build-publish. |
Build-info records resolved dependencies, produced artifacts, environment variables, and other metadata from the build. See About Build Info for details.
| CI Servers | ||||||||
|---|---|---|---|---|---|---|---|---|
| Package Type | JFrog Pipelines | JFrog CLI | Jenkins | Bamboo | TeamCity | Azure DevOps | GitHub Actions | Bitbucket Pipelines |
| Generic |  | | | | | | | |
| Conan | | | | | | |||
| Docker | | | | | | | | |
| Podman | | |||||||
| Kaniko | | | ||||||
| Go | | | | | | | ||
| Gradle | | | | | | | | |
| Ivy | | | | |||||
| Maven | | | | | | | | |
| npm | | | | | | | | |
| Yarn | | | | |||||
| NuGet | | | | | | | ||
| Python | | | | | |
Updated 6 days ago