Artifactory 7.104.5 Self-Hosted

• Updated Minimum System Requirements

  To support the new services for our self-hosted customers, we have increased the minimum system resources required to run JFrog Artifactory.

  Warning

  Review the resources and make adjustments to your environment to ensure effective support for the new services in JFrog Artifactory. For more information, see System Requirements.

• Java 21 Compatibility

  Artifactory now officially supports JDK 21. All Artifactory distributions are pre-packaged with JDK 21.

  Breaking Change for Groovy

  Java 21 is compatible with Groovy version 4.x, which includes several improvements and breaking changes compared to Groovy 3. If you have developed custom JFrog user plugins using Groovy, review your code and ensure it is compatible with Groovy 4.x.

  If you are using the Promotion User plugin, ensure that you are using the latest plugin version. For more information, see Upgrade Notice: Groovy 4 Compatibility.

  Breaking Change for LDAP Authentication Rollback

  Starting from Artifactory version 7.71.x, LDAP authentication has been moved to the Access Service.

  The LDAP implementation on the Artifactory service will only work if the Secure LDAP Search (Poisoning Protection) feature is enabled. If you have rolled back to the previous implementation, you must remove this rollback. This will help you to avoid conflicts.

  If you are using LDAP authentication via Access Service, you will not have any impact.

• New Services - Topology and One Model

  We have added some new services for our Self-Hosted instances:

  • JFrog Topology is a service registry that streamlines platform topology management.

  • One Model is a service that acts as a centralized hub for all GraphQL APIs. This also includes a third-party service called Apollo Router.

  For more information, see Artifactory Product.JFrog Artifactory Product

• Evidence service

  JFrog's new Evidence service generates an audit trail that documents all the security, quality, and operational steps taken to produce a production-ready software release. It enriches artifacts, packages, builds, and Release Bundles with signed attestation metadata (based on the in-toto Attestation Framework) that can be tracked and verified easily for governance and compliance. The Evidence service enables you to seamlessly consolidate information from all the tools and platforms used in software development into a trusted single source of truth. It also integrates seamlessly with Release Lifecycle Management, providing a graphical interface for viewing the evidence generated at each stage of your SDLC.Understanding Release Bundles v2Release Lifecycle Management

  Artifactory creates signed evidence automatically when Release Bundles are promoted and distributed. When used in conjunction with JFrog Xray, additional evidence is created in the form of SBOMs and vulnerability reports.Promote a Release Bundle (v2) to a Target EnvironmentDistribute Release Bundles (v2)

  In addition, Enterprise+ users can attach externally-produced evidence to artifacts, packages, builds, and Release Bundles using the JFrog CLI.

  For more information, see Evidence Management.Evidence Management

  Important

  The current release of the Evidence service is subject to the following limitations in Self-hosted environments:

  • Kubernetes is required. For more information, see Installing Evidence. Support for non-Kubernetes installations is planned for late Q1 2025. Installing Evidence

  • The Evidence service requires PostgreSQL 12 or later. (Please note that Artifactory can continue working with any supported database. There is no need to migrate Artifactory to PostgreSQL to support the Evidence service.)Database Configuration

• Artifactory Federation Service

  To meet the growing needs of customers, JFrog has moved the Federated repositories feature into a standalone, multi-tenant service to ensure the timely synchronization of huge volumes of artifact metadata between customer sites. The new standalone service offers the following benefits:Federated Repositories

  • Scalability: The Federation service is designed from the ground up to grow as the needs of our customers grow.

  • Automatic Federation recovery: The Federation service features an improved auto-healing mechanism that can identify synchronization problems between members due to an exhausted queue (a queue that has exceeded the maximum number of attempts to send metadata events to other members), reset the failed events, and retry synchronization. This capability is particularly useful in the event a Full Sync operation is interrupted by a restart of one of the Artifactory instances that host a Federation member. For more information, see Federation Recovery and Auto-Healing.Federation Recovery and Auto-Healing

  • Improved monitoring using the Federation dashboard: The new Federation dashboard enables you to:

    • Understand the health status of all your repository Federations at a glance. The dashboard makes it particularly easy to see how many repositories are in error or delayed. For more information, see View the Status of All Repository Federations.View the Status of All Repository Federations

    • Drill down into a selected Federation to see the state of each member at a glance. For more information, see View the Status of a Selected Repository Federation.View the Status of a Selected Repository Federation

    • Give selected repositories priority to system resources to help ensure all their metadata events are synchronized with other Federation members. For more information, see Prioritize Federated Repository.Prioritize Federated Repository

  Important

  The current release of the standalone Artifactory Federation service is subject to the following limitations in Self-hosted environments:

  • Kubernetes is required. For more information, see Installing Artifactory Federation Service. Support for non-Kubernetes installations is planned for late Q1 2025.Installing Artifactory Federation Service

  • The Artifactory Federation service requires PostgreSQL 12 or later. (Please note that Artifactory can continue working with any supported database. There is no need to migrate Artifactory to PostgreSQL to support the Artifactory Federation service.)Database Configuration

  • Providing support for other databases is under consideration.

• Using the Federation Comparison Tool on Federated Repositories

  Users who have the Artifactory Federation Service installed can use the Federation Comparison Tool to compare the state of a Federated repository with one or more remote members to detect missing artifacts in those remote members. This enables you to simulate the results of a Full Sync operation before you perform it. The Federation Comparison tool is invoked using a new query parameter in the Federated Repository Full Sync REST API. For more information, see Use the Federation Comparison Tool.Artifactory Federation ServiceFederated Repository Full SyncUse the Federation Comparison Tool

• Machine Learning Repositories

  Machine Learning Repositories with the FrogML SDK is a local management framework tailored for machine learning projects, serving as a central storage for models and artifacts, featuring a robust version control system. It offers local repositories and an SDK for effortless model deployment and resolution.

  Machine Learning Repositories offer the following benefits to your system:

  • Secure Storage: Protect your proprietary information by deploying models and additional resources to Artifactory local repositories, giving you fine-grain control of the access to your models.

  • Easy Collaboration: Share and manage your machine learning projects with your team efficiently.

  • Easy Version Control: The Machine Learning Repositories SDK (FrogML) provides a user-friendly system to track changes to your projects. You can name, categorize (using namespaces), and keep track of different versions of your work.

  For information on Machine Learning Repositories, click here.Machine Learning Repositories

• Helm Enforce Layout

  Helm Enforce Layout is designed to maintain the integrity and organization of Helm charts within your repositories. It consists of two key functionalities that promote structure and reduce errors during deployments: 

  • Preventing duplicate chart paths: Prevents the deployment of charts with the same name and version to different paths within the same repository, by ensuring that only a single instance of a chart is indexed. This maintains the integrity and accessibility of Helm charts, ensuring that users can easily identify and deploy the desired version without confusion.

  • Enforcing chart names and versions: Ensures that the chart name and version specified in the packaged file name match the values in Chart.yaml and adhere to Semantic Versioning (SemVer) standards adopted by the Helm official specification. Enforcing these rules promotes uniformity, allowing teams to adopt clear naming conventions that foster better collaboration and understanding of changes across different versions.

  For more information on Helm Enforce Layout, click here.Helm Enforce Layout

  Note

  Helm Enforce Layout is forward-compatible only, it will not work on repositories created prior to Artifactory 7.104.2. This means that even if you upgrade to Artifactory 7.104.2, any repositories created prior to the upgrade are not compatible with this feature. Enforcement is set only upon repository creation.

• Cleanup Policies: Release Bundle v2

  JFrog Cleanup Policies for Release Bundle v2 enable Platform and Project Administrators to define and customize policies based on specific criteria for removing unused Release Bundles across their JFrog platform. This provides optimal system performance. Administrators can customize a repeatable cleanup process that aligns with their organization's requirements by setting specific criteria and rules. For more information, refer to CLEANUP POLICIES.CLEANUP POLICIES

• Packages and Repositories

  • New REST API for Checking Repository Existence

    A new REST API has been added to check whether a repository exists based on the project key and repository type. For more information, click here.Check If Repository Exists

  • Improvements to Conan Reindexing Speed on Large Repositories

    The process for reindexing large Conan repositories has been optimized and is now half the time from what it was previously. Added Conan packages are available for indexing immediately even during the reindexing process.

  • Added Clients for PyPI Repositories

    PyPI repositories now support Poetry and Twine clients. For more information, click here.Set up PyPI Clients to Work with Artifactory

  • Updating multiple repositories using a batch request

    It is now possible to update the configuration of multiple repositories using a single batch request. The request can contain a mixture of package types (for example, Docker and Maven) and repository types (for example, local and remote). For more information, see Update Multiple Repositories.Update Multiple Repositories

  • Viewing contents of Release Bundle v2 versions by package type

    The window for viewing the contents of a Release Bundle v2 version has been redesigned to organize the contents according to package type. You can drill down from a package type to individual packages and from there, click a link to see the individual artifacts. For more information, see View the Contents of a Release Bundle (v2).View the Contents of a Release Bundle (v2)

  • Promoting Release Bundle v2 versions to virtual repositories

    You can now promote a Release Bundle v2 version to a virtual repository, provided it contains at least one local repository assigned to the same environment as the virtual repository (or no environment at all). For more information about promotion, see Promote a Release Bundle (v2) to a Target Environment.Promote a Release Bundle (v2) to a Target Environment

  • Virtual repositories can include repositories not assigned or shared to the same project

    You can now edit a virtual repository configuration that contains local and remote repositories which are not assigned to, or shared with, the same project as the virtual repository. If such repositories are aggregated, a message appears in the UI. Click the button next to the message to display a list of these repositories. You can export this list to a CSV file. For more information, see Virtual Repositories and Projects.Assign Multiple Projects to ResourcesShare Repositories Across Multiple ProjectsProjectsSelect Repositories to Include in a Virtual Repository

    Note

    Users who can perform actions on the virtual repository (based on their assigned roles in the relevant project) are not automatically granted permissions to aggregated repositories not assigned or shared with the same project.Manage Project Roles and Members

• Storage

  • Improved Retry Mechanism for the google-storage-v2 Provider

    The google-storage-v2 provider now supports an improved retry mechanism when Google Cloud Storage returns 50x errors during binary download. The retry behavior is controlled by the maxRetries and retryIntervalMillis configuration parameters. For more information, click here.Google Storage Binary Provider Native Client Template

  • Improved Optimize System Storage REST API

    The Optimize System Storage REST API now triggers the balancing mechanism immediately instead of raising a flag to indicate that Artifactory should run the balancing mechanism in the next Full Garbage Collection cycle. If balancing is already running, the API skips the process. For more information, see the Optimize System Storage REST API documentation.Optimize System Storage

• Release Lifecycle Management

  • New Content tab in Release Lifecycle Management timeline

    The Release Lifecycle Management timeline contains a new Content tab that lists the artifacts in the selected Release Bundle v2 version. For more information, see View the Contents of a Release Bundle (v2).Use the Release Bundle Version TimelineView the Contents of a Release Bundle (v2)

  • Support for default key creation for Release Bundles v2 via REST API

    It is now possible to create a Release Bundle v2 using the REST API without specifying an existing signing key. In such cases, Artifactory creates a default GPG key that is used to sign the Release Bundle. This default key is then used for future Release Bundles unless a different key is selected during Release Bundle creation. The default key created by Artifactory is displayed in the Keys Management table.Create Release Bundle v2 VersionSecurity Keys Management

    Note

    In the current release, a default key is created only when creating the Release Bundle v2 using the REST API. It is still mandatory to select an existing signing key when using the JFrog CLI or platform UI.Create a New Release Bundle v2 in the Platform UI

  • Support for default key creation for Release Bundles v2 in the platform UI

    It is no longer mandatory to select a signing key when creating a Release Bundle v2 with the platform UI. If you do not select a key, Artifactory uses a default GPG key that it creates automatically. The default key is then used for future Release Bundles unless a different key is selected during Release Bundle creation. The default key created by Artifactory is displayed in the Keys Management table.Create a New Release Bundle v2 in the Platform UISecurity Keys Management

    Note

    Support for the default key will be added to the JFrog CLI in an upcoming release.

• Federated Repositories

  • Performance enhancement for Federated repositories

    A new system property enables event properties to be fetched in bulk from the database, which improves overall performance when mirroring among Federation members. For more information, see Configure Federated Repositories for Bulk Mirroring and Parallel Processing.Configure Federated Repositories for Bulk Mirroring and Parallel Processing

  • Converting Federated repositories back to local

    You can now convert a Federated repository back to a local repository using a REST API, provided it is not part of a Federation containing additional members. For more information, see Convert Federated Repository to a Local Repository.Convert Federated Repository to a Local Repository

• OCI and Docker Related Changes

  • Enhanced Docker List Tags REST API Compatibility

    The Docker List Tags REST API has been enhanced to support both the full and shorthand conventions for referencing official Docker images. Users can now retrieve tags using either the complete path (including /library/) or the shorter version without it. For more information about the API see List Docker Tags.List Docker Tags

  • Enhanced Webhook Event Support for OCI and Docker Images

    In this release, the Webhook events functionality for Docker images has been expanded to include support for OCI repositories and images. These enhancements made include:

    • Support for OCI Repositories: Webhook events can now be triggered for OCI repositories, broadening the integration capabilities.

    • Support for OCI Images: Events related to OCI images are now fully supported, ensuring that actions on these images are captured.

    • New image_type Key: A new image_type key has been added to the event action payload, indicating whether the action was performed on an OCI or Docker image.

    For more information, click here.Domain: Docker

  • Additional Keys Added to the Webhook Promoted Event in the Docker Domain

    The Image Promotion Webhook in the Docker domain has been expanded with two additional keys:

    • targetRepo: The repository where the image is promoted to.

    • targetTag: The new tag of the promoted image.

    For more information, click here.Domain: Docker

JFrog Platform

• Setting upper limits on property updates

  A new system parameter has been introduced (artifactory.max.artifacts.set.properties.recursive) for setting an upper limit on the number of artifacts on which recursive property updates can be performed. For example, if you revise a folder property and the folder contains more items than the limit defined in this system parameter, the operation will fail. This property can be used to throttle the number of update requests, which can put a heavy load on the database and in extreme cases lead to crashes. By default, this feature is off. There is no default value when turned on.

• Platform Chart 11.x Release

  We have released the JFrog Platform Helm Chart 11.x, which includes some of the important changes:

  • Removal of Insight and Pipelines: We have removed the Insights and Pipelines chart dependencies from the JFrog Platform chart 11.x.

  • Upgrade of Bitnami PostgreSQL and RabbitMQ Helm Charts: Upgraded the RabbitMQ chart version and the image version of PostgreSQL and RabbitMQ.

  The JFrog Platform chart 11.x also includes multiple breaking changes. For more information, see Platform chart 11.x: Breaking Changes.

• Enabling SSO Disables Basic Authentication By Default

  Enabling single sign-on authentication now disables internal password authentication by default. For more information, see Disable Basic Authentication Method.Disable Basic Authentication Method

• Improvements in Obtaining AQL Results

  The Search AQL API was improved such that AQL results are complete and not missing properties. A notification is now provided informing the client when the AQL limit has been reached.

• Improved Performance for the Fetching Process

  Performance of the fetching process has been improved, based on the count of manifests relative to the Max Unique Tags configuration.

• Cleanup Policies

  • Terraform: Terraform packages are now supported in Cleanup.

  • Terraform BE Packages : Terraform BE packages are now supported in Cleanup and Archive.

  • CocoaPods: CocoaPod packages are now supported in Cleanup.

  • Hugging Face: Hugging Face packages are now supported in Cleanup.

  • OCI: Helm OCI and OCI packages are now supported in Cleanup and Archive.

  • Cargo: Cargo packages are now supported in Cleanup and Archive.

  • Frog ML: Frog ML models are now supported in Cleanup and Archive.

  • Ansible: Ansible packages are now supported in Cleanup and Archive.

• Support for Scheduled Workers

  JFrog now supports creating scheduled workers to trigger at predefined times or intervals, which you can define using Cron expressions. Learn moreCreate a Scheduled Worker

• Worker Events

  • Replication: Before Directory Replication event is now supported.

  • Storage: After Copy event is now supported.

  • Storage: After Property Delete event is now supported.

  • Storage: After Property Create event is now supported.

  • Storage:beforeCreate: beforeCreate event is now supported.

  • Storage:beforeCopy: beforeCopy event is now supported.

  • Before Build Info Save: Before Build Info Save event is now supported.

  • Before Download Request: Before Download Request event is now supported.