JFrog has transitioned from an artifact repository to a DevOps Platform that includes CI and CD capabilities through its acquisition of Shippable in Feb 2019. Recently in March 2020, JFrog announced the launch of its DevOps platform called ‘JFrog Platform’, a pre-integrated solution with a common UI across JFrog Pipelines, JFrog X-Ray and JFrog Source Composition Analysis products. This solution is backed by a common meta data model that facilitates information integration between these separate product. In addition to three primary products JFrog Artifactory, JFrog Pipelines and JFrog Xray, JFrog also provides other products such as JFrog Distribution, JFrog Mission Control and JFrog Container Registry.
JFrog Artifactory
JFrog Artifactory is a tool designed to store the binary output of the build process for use in distribution and deployment. Artifactory is an industry leading product and provides support for 25 package formats (as of 14 Oct, 2020). JFrog Artifactory provides a single source of truth for build artifacts and works with JFrog Distribution to efficiently distribute large artifacts across the enterprise.
GitLab package registry supports 8 different package types.
JFrog Pipelines
JFrog Pipelines is a CI-CD product that works well with its Artifactory repository. JFrog pipelines works through a combination of native steps and resources. Native steps are a set of higher order steps built on bash. Resources inputs into a step or outputs from native steps. Resources can be any type such as a build, integration etc. JFrog pipelines is a functional CI-CD product, though it lacks several capabilities typically found in enterprise class products.
JFrog Xray
JFrog Xray is a security product that can be built-into various steps within a JFrog pipeline. Xray supports detecting security vulnerabilities in all dependent code and also provides license compliance capabilities. JFrog X-Ray supports 14 package formats (as of 14 Oct, 2020).
GitLab dependency scanning supports 15 package managers spanning 8 languages.
FEATURES | JFrog |
|
---|---|---|
Built-in Container Registry
GitLab Container Registry is a secure and private registry for Docker images. It allows for easy upload and download of images from GitLab CI. It is fully integrated with Git repository management. (Codefresh will be ending their support for private docker registries as of May 1, 2020 |
|
|
Docker image support
Supports storage and retrieval of Docker style containers. |
|
|
Container registry webhooks
Trigger actions after a successful push to a registry to integrate Docker Hub with other services. |
|
|
Container registry high availability
Highly available through the use of multiple replicas of all containers and metadata such that if a machine fails, the registry continues to operate and can be repaired. |
|
|
Container Registry geographic replication
Supports distributed teams by running multiple registry instances across several regions and syncing between data centers. |
|
|
Supports private container registries
Offers the ability to have private container registries and repositories |
|
|
SaaS container registry offering
The container registry is available as a software service. Learn more about the container registry available on GitLab.com |
|
|
Use container registry through REST API
Enables support for automation and integration of container registry through a REST API. |
|
|
Container registry storage management
In the context of the Docker registry, garbage collection is the process of removing blobs from the filesystem when they are no longer referenced by a manifest. |
|
|
Use search to find and container images
Search your group and project’s Container Registry by image name |
|
|
Helm chart repository support
Supports storage and retrieval of Helm charts. |
|
|
Container image cleanup policies
Easily define, manage and update project-level policies to define which images should be removed and preserved. This feature is designed to help you reduce storage costs and prevent important images from being deleted. |
|
|
Virtual registries
A virtual registry is a collection of local, remote and other virtual registries accessed through a single logical URL. GitLab Epic detailing the issues required to add this functionality. |
|
|
Forward requests for npm packages not found in GitLab to npmjs.com
By default, when an npm package is not found in the GitLab registry, the request is forwarded to npmjs.com |
|
|
Forward requests for Python packages not found in GitLab to PyPI.org
By default, when a PyPI package is not found in the GitLab registry, the request is forwarded to PyPI.org |
|
|
Conan (C/C++) Repository
Conan is an open source, decentralized and multi-platform C/C++ Package Manager for developers to create and share native binaries. |
|
|
Maven (Java) Repository
GitLab’s Maven repository makes it easier to publish and share Java libraries across an organization, and ensure dependencies are managed correctly. It is fully integrated with GitLab, including authentication and authorization. |
|
|
npm (node) Registry
GitLab’s NPM repository makes it easier to publish and share NPM packages across an organization, and ensure dependencies are managed correctly. It is fully integrated with GitLab, including authentication and authorization. |
|
|
NuGet (.NET) Repository
GitLab’s NuGet Repository allows C#/.NET developers to create, publish and share packages using the NuGet client or visual studio. |
|
|
PyPI (Python) Repository
Python developers can set up GitLab as a remote PyPI repository and build, publish, and share packages using the PyPI client or GitLab CI/CD. |
|
|
RPM (Linux) Repository
This planned feature will enable Linux developers to build, publish and share RPM packages alongside their source code and pipelines. Check out the issue for additional details on implementation and timing |
|
|
Debian (Linux) Repository
This planned feature will enable Linux developers to build, publish and share Debian packages alongside their source code and pipelines. Check out the issue for additional details on implementation and timing |
|
|
RubyGems (Ruby) Repository
This planned feature will enable Ruby developers to setup GitLab as a remote RubyGems repository and to build, publish and share packages using the command line or GitLab CI/CD. This will also be a valuable feature for GitLab and help with dogfooding Check out the issue for additional details on implementation and timing |
|
|
Go Proxy
This feature helps Go developers to publish and share their packages right alongside their source code and pipelines. This will also be a valuable feature for GitLab and help with dogfooding |
|
|
Composer (PHP) Repository
This feature helps PHP developers to build, publish and share their packages right alongside their source code and pipelines. |
|
|
Use the Package Registry through REST API
Enables support for automation and integration of the GitLab Package Registry through a REST API. |
|
|
Package debugging with an integrated web terminal
Easily debug your packages in any of your environments using the built-in GitLab Web Terminal. GitLab can open a terminal session directly from your environment if your application is deployed on Kubernetes. This is a very powerful feature where you can quickly debug issues without leaving the comfort of your web browser. |
|
|
Publish and share package versions
Each version of a package is nested under its uniquely-named parent. Now you can easily find the package you are looking for in the UI and better understand what has changed from version to version. |
|
|