Artifactory 7.90

RTDEV-50656

NPM metadata request to a virtual repository is causing a DB query that will outcome with high database CPU.

7.98.17

RTFACT-31038

An unannounced change was introduced by Conda Forge upstream which impacts Artifactory's ability to resolve package metadata and dependencies with virtual Conda repositories. For more information see this article.

7.90.19

Suggested workaround:

Use the Conda Remote Repository Directly: Instead of relying on the Virtual Conda repository, users can directly use the Conda remote repository (repo.anaconda.com/conda-forge) to download packages.

RTDEV-47671

Build Info Publish failed when the same artifact was used in the build more than once, even though previously it succeeded.

Self-Hosted: 7.90.15

Cloud: 7.98.5

A new Artifactory System Property was added named artifactory.build.block.duplicate.entries and is set to true by default. When set to true, Build Info Publish operations that have duplicate entries fail and and results in an error.

Note: This means that previous jobs that would pass in the Build Info Publish stage may now fail. This property can be changed to false to turn off validation and allow duplicate entries with Build Info Publish.

INST-8700

Under certain circumstances, when running an Artifactory non-containerized installation with a container engine available on the same virtual machine, the isRunningInsideAContainer function falsely identifies the installation as in a container, which results in Artifactory startup failure.

TBD

The startup script uses the method isRunningInsideAContainer, which has a condition called grep -sq 'containers' /proc/self/mountinfo which returns true in cases where a container engine (e.g. Docker) is installed and running some container with a volume mount.

RTDEV-46858

Redirect signed URLs are not working when using the cluster-sharding provider with a cloud provider in the binarystore chain and templates such as: cluster-s3-storage-v3, cluster-google-storage-v2 and cluster-azure-blob-storage-v2.

7.90.9

Suggested workaround:

To mitigate this issue, switch to use a direct chain such as: s3-storage-v3-direct.

RTDEV-46671

S3 Cold storage fails to put binaries in the Glacier Tier.

7.90.8

RTDEV-46659

When redirecting to S3, the downloads are served directly from Artifactory instead of the S3 bucket. Also, when using CloudFront, the redirect fails and the download will not work.

7.90.8

Suggested workaround:

To resolve this issue, add a header in the reverse proxy to set X-JFrog-Download-Redirect-To: S3 as described in Control your Signed URL DownloadsStep 4: Control Your Signed URL Downloads

RTDEV-44707

A Tomcat upgrade that was implemented due to a security fix disrupts the Pub client upload flow.

7.90.7

Artifactory 7.90.6 has been removed. Customers should upgrade to Artifactory 7.90.7.

RTDEV-44298

Upgrades of existing Artifactory installations using a Derby database to Artifactory 7.90.5 might fail due to the JFMD service mistakenly forcing the value of  allowNonPostgresql system configuration to be set as  true.

7.90.6

Expected error to be presented in the logs:

Could not set db properties to application configuration - type: 'sqlite' is not allowed

Suggested workaround:

Add the following configuration settings:

shared:
  database:
    allowNonPostgresql: true

to the file $JFrog_HOME/var/etc/system.yaml and restart Artifactory.

JFrog highly recommends using PostgreSQL. For more information, see Choose the right database.Choose the right database