Upgrading Artifactory Enterprise / HA
Note |
---|
title | There are different instructions for upgrading Artifactory HA |
---|
|
When upgrading an HA cluster, the procedure for upgrading each node is similar to upgrading a single instance (Non-HA) installation, however, there are additional actions required for the nodes to operate as a high availability cluster. If you are upgrading an Artifactory HA cluster, please refer to Upgrading an Enterprise HA Cluster. |
Upgrading to the Latest Version
Note |
---|
title | server.xml file default changes from Artifactory 6.10 |
---|
|
From version 6.10, new Artifactory installations will not include the AJP connector in Artifactory’s Tomcat server.xml file (i.e. under $ARTIFACTORY_HOME/tomcat/conf/server.xml). To use AJP connector, the <Connector port="8019" protocol="AJP/1.3" sendReasonPhrase="true"/> should be added manually to the server.xml file under <Service name="Catalina">. Upgraded Artifactory environments will be unchanged provided the server.xml file is copied over. Notice: AJP connector support will be removed in Artifactory's next major version (7.0). |
Upgrading from version 4.x or 5.x to the latest version is a simple procedure. Please refer to the sections below with specific instructions for your installation type.
Upgrading from any version prior to 6.14 to any version above 6.14 requires root privileges while running the upgrade process. Upgrading post version 6.14 does not require this.
Excerpt |
---|
ZIP Installation Expand |
---|
title | Upgrading a ZIP installation... |
---|
| - Unzip the Artifactory distribution archive.
- If you have not yet done so, perform a graceful shutdown of your currently running installation.
If the $ARTIFACTORY_HOME /tomcat/conf/server.xml has been modified keep it in a temporary location. - Backup files to a temporary location according to the conditions described below:
- In all cases, backup
$ARTIFACTORY_HOME/bin/artifactory.default - If Artifactory is configured to work with a database that is not Derby, backup the
$ARTIFACTORY_HOME /tomcat/lib/<JDBC> driver.
- Remove the following files and folders from your
$ARTIFACTORY_HOME folder:
- Replace the removed files and folders with the corresponding ones from the new unzipped version.
Any files that were stored in temporary locations should now be returned to their original location under the new installation. Note |
---|
title | Running Artifactory as a ROOT application in Tomcat |
---|
| If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps described in Newtablink |
---|
Text | this Knowledge Base article |
---|
URL | https://www.jfrog.com/knowledge-base/how-do-i-setup-artifactory-to-run-as-the-root-application-in-tomcat/ |
---|
| . |
Note |
---|
title | Version-specific Special Instructions |
---|
| To accommodate internal changes in Artifactory in different version upgrades, you need to perform or ensure certain changes to Artifactory's server.xml according to your target upgrade version. Note that the changes listed below are cumulative as the versions progress. Upgrading to version 5.4.0 and above From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, JFrog Access, installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see <Host name="localhost" appBase="webapps" startStopThreads="2"/>): Code Block |
---|
...
<Engine name="Catalina" defaultHost="localhost">
<Host name="localhost" appBase="webapps" startStopThreads="2"/>
</Engine>
... |
Upgrading to version 5.6.1 and above In version 5.6.1, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate YUM clients following this upgrade, a new attribute, sendReasonPhrase was added for each Tomcat connector in the server.xml file as shown in the example below: Code Block |
---|
<Connector port="8081" sendReasonPhrase="true"/> |
Upgrading to version 5.7.0 and above From version 5.7.0, Artifactory routes requests to its Access service directly through a port, and this requires the following modification to the server.xml file Code Block |
---|
<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/> |
Upgrading to version 6.3 and above From version 6.3, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate special characters following this upgrade, the following new attributes, relaxedPathChars='[]' relaxedQueryChars='[]' were added for each Tomcat connector in the server.xml as shown in the example below:
Code Block |
---|
<Service name="Catalina">
<Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/> |
|
- If you installed Artifactory as a service, you now need to run the service
For a Linux service, browse to $ARTIFACTORY_HOME/bin and execute the following command as root: $ARTIFACTORY_HOME/bin/installService.sh [USER [GROUP]] - For Windows service, browse to %ARTIFACTORY_HOME%\bin. First uninstall the service by running
uninstallService.bat , then reinstall the service by running installService.bat . You can now run the service through the Windows UI or as described in Running Artifactory.
|
Debian Installation Expand |
---|
title | Upgrading a Debian installation... |
---|
| - Log in as root (or use
sudo su - ). - If you have not yet done so, perform a graceful shutdown of your currently running installation
Execute the following command: Code Block |
---|
dpkg -i $jfrog-artifactory-<oss|pro>-6.y.z.deb |
Managing Configuration FilesWhen upgrading a Debian installation the upgrade process overwrites the following set of configuration files: system.properties config.xml default logback.xml mimetypes.xml - All files under
opt/jfrog/artifactory/misc - All files under
opt/jfrog/artifactory/webapps
If any of these files were modified, a backed up file will be created automatically with a notification in the upgrade log. If you need to restore the configuration changes you can restore them from the backup created. Note |
---|
title | Running Artifactory as ROOT |
---|
| If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps described in Newtablink |
---|
Text | this Knowledge Base article |
---|
URL | https://www.jfrog.com/knowledge-base/how-do-i-setup-artifactory-to-run-as-the-root-application-in-tomcat/ |
---|
| . |
Note |
---|
title | Version-specific Special Instructions |
---|
| To accommodate internal changes in Artifactory in different version upgrades, you need to perform or ensure certain changes to Artifactory's server.xml according to your target upgrade version. Note that the changes listed below are cumulative as the versions progress. Upgrading to version 5.4.0 and above From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, JFrog Access, installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see <Host name="localhost" appBase="webapps" startStopThreads="2"/>): Code Block |
---|
...
<Engine name="Catalina" defaultHost="localhost">
<Host name="localhost" appBase="webapps" startStopThreads="2"/>
</Engine>
... |
Upgrading to version 5.6.1 and above In version 5.6.1, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate YUM clients following this upgrade, a new attribute, sendReasonPhrase was added for each Tomcat connector in the server.xml file as shown in the example below: Code Block |
---|
<Connector port="8081" sendReasonPhrase="true"/> |
Upgrading to version 5.7.0 and above From version 5.7.0, Artifactory routes requests to its Access service directly through a port, and this requires the following modification to the server.xml file Code Block |
---|
<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/> |
Upgrading to version 6.3 and above From version 6.3, the version of the Tomcat embedded in Artifactory was upg Code Block |
---|
<Service name="Catalina">
<Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/> |
Upgrading to version 6.14.0 and above From version 6.14.0, the systemd runs successfully. Prior to upgrading to this version perform the following steps: Stop Artifactory by running the following command. Ignore any errors that may arise, and allow it to run to disable the auto start by systemd. Code Block |
---|
systemctl stop artifactory.service |
Kill any running Artifactory Java process that may still be running, using the following command: Code Block |
---|
ps -ef | grep java | grep artifactory | grep tomcat |
Rename the existing /etc/opt/jfrog/artifactory/default file to the new artifactory.pid file location: Code Block |
---|
export ARTIFACTORY_PID=/var/run/artifactory.pid |
Run the new Debian installation Start Artifactory by running the following command: Code Block |
---|
systemctl start artifactory.service |
|
|
Expand |
---|
title | Upgrading Debian OSS to Pro |
---|
| To ensure that all of the data remains in Artifactory following the upgrade to Pro (assuming you are using the default DB), please follow these steps: - Perform a graceful shutdown of your currently running installation.
- Perform a backup of $ARTIFACTORY_HOME/data folder.
Delete the OSS installation. Code Block |
---|
apt-get remove jfrog-artifactory-oss) |
Download and install the Pro package. Code Block |
---|
dpkg -i $jfrog-artifactory-pro-<version>.deb) |
Import the ‘data’ backup folder to the new installation location. Code Block |
---|
$ARTIFACTORY_HOME/data |
Start Artifactory. Code Block |
---|
$ARTIFACTORY_HOME/data |
|
Docker Installation Expand |
---|
title | Upgrading a Docker installation... |
---|
| In order to keep your data and configuration between versions, when upgrading the Artifactory Docker image, you need to use an external mounted volume as described under Managing Data Persistence. To upgrade the Artifactory Docker image, follow these steps: - Stop the current container
- Start a container with the new version using same data and configuration
- Remove the old container
The example below shows this process for upgrading Artifactory from v5.0.0 to v5.1.0. Code Block |
---|
$ # Stop the currently running container
$ docker stop artifactory-5.0.0
$ # Start a new container from the new version image
$ docker run -d --name artifactory-5.1.0 --volumes-from=artifactory-5.0.0 -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:5.1.0
$ # Remove old container
$ docker rm artifactory-5.0.0 |
Once these commands have completed successfully, you would have the new version (5.1.0 in the above example) running with the data and configuration from the old version that was removed. Note |
---|
title | Running Artifactory as ROOT |
---|
| If you have configured Artifactory to run as the ROOT application in Tomcat, you need to follow the steps described in Newtablink |
---|
Text | this Knowledge Base article |
---|
URL | https://www.jfrog.com/knowledge-base/how-do-i-setup-artifactory-to-run-as-the-root-application-in-tomcat/ |
---|
| . |
Note |
---|
title | Version-specific Special Instructions |
---|
| To accommodate internal changes in Artifactory in different version upgrades, you need to perform or ensure certain changes to Artifactory's server.xml according to your target upgrade version. Note that the changes listed below are cumulative as the versions progress. Upgrading to version 5.4.0 and above From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, JFrog Access, installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see <Host name="localhost" appBase="webapps" startStopThreads="2"/>): Code Block |
---|
...
<Engine name="Catalina" defaultHost="localhost">
<Host name="localhost" appBase="webapps" startStopThreads="2"/>
</Engine>
... |
Upgrading to version 5.6.1 and above In version 5.6.1, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate YUM clients following this upgrade, a new attribute, sendReasonPhrase was added for each Tomcat connector in the server.xml file as shown in the example below: Code Block |
---|
<Connector port="8081" sendReasonPhrase="true"/> |
Upgrading to version 5.7.0 and above From version 5.7.0, Artifactory routes requests to its Access service directly through a port, and this requires the following modification to the server.xml file Code Block |
---|
<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/> |
Upgrading from version 6.3 and above From version 6.3, the version of the Tomcat embedded in Artifactory was upgraded. To accomodate special characters following this upgrade, the following new attributes, relaxedPathChars='[]' relaxedQueryChars='[]' were added for each Tomcat connector in the server.xml as shown in the example below: Code Block |
---|
<Service name="Catalina">
<Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/> |
|
|
RPM Installation Expand |
---|
title | Upgrading an RPM installation... |
---|
| Warning |
---|
title | Make sure you are upgrading from v3.6 or above |
---|
| When running as an RPM installation, you can only upgrade to v5.x if your current version is 3.6 or above. If necessary, first upgrade your current version to 3.6, and then upgrade to v5.x . If you try to upgrade a version below 3.6 using rpm --force you may end up deleting all of your data. |
- Download the Artifactory Pro RPM Installer. The latest version can be downloaded from the
Newtablink |
---|
Text | JFrog Artifactory Pro Download Page |
---|
URL | https://bintray.com/jfrog/product/artifactory/download |
---|
| . Previous versions can be downloaded from Newtablink |
---|
Text | JFrog Bintray |
---|
URL | https://jfrog.bintray.com/artifactory-pro-rpms/org/artifactory/pro/rpm/ |
---|
| . - Log in as root (or use
sudo su - ). - If you have not yet done so, perform a graceful shutdown of your currently running installation
Execute the following command: Code Block |
---|
rpm -U jfrog-artifactory-pro-6.y.z.rpm |
Note |
---|
title | Switching from Artifactory OSS to Pro |
---|
| If you are just switching from Artifactory with the same version number, you need to append the command with --force --nodeps as follows: rpm -U jfrog-artifactory-pro-6.y.z.rpm --force --nodeps |
During an upgrade of an RPM installation different files may get backed up, where the backup file is appended with either a .rpmorig or a .rpmnew extension. A .rpmorig extension means that the original file in your installation, the one that was there before performing the upgrade, was backed up before being replaced in the upgrade process. A .rpmnew extension means that the original file in your installation, was not replaced in the upgrade, and instead, the new file with the same filename was backed up. In either case, Artifactory will display a message such as: warning: /etc/opt/jfrog/artifactory/default saved as /etc/opt/jfrog/artifactory/default.rpmorig In these cases we recommend comparing the file installed once the upgrade has been completed with the backed-up file to see which best fits your needs, and using that one in the final setup. If you make any changes, you may need to restart Artifactory for the change to be applied. Upgrading Using YUMAn easy way to upgrade Artifactory from version 3.x or 4.x to the latest version is to use YUM with the Bintray Artifactory repository. The code snippets below show how to do this depending on whether your current version is below 3.6, or 3.6 and above. Note |
---|
title | Upgrading an Artifactory HA cluster? |
---|
| If you are upgrading an Artifactory HA cluster, and you are running with a version that is older than version 5.4.6, you should review the instructions on Upgrading an Enterprise HA Cluster prior to upgrading. |
Expand |
---|
title | If your current version is 3.6 and above: |
---|
| Code Block |
---|
curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpms.repo && sudo mv bintray-jfrog-artifactory-pro-rpms.repo /etc/yum.repos.d
yum install jfrog-artifactory-pro-6.y.z |
Tip |
---|
To install the latest version of Artifactory, you can run: yum install jfrog-artifactory-pro |
|
Expand |
---|
title | If your current version is below 3.6: |
---|
| Code Block |
---|
curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpms.repo && sudo mv bintray-jfrog-artifactory-pro-rpms.repo /etc/yum.repos.d
yum upgrade artifactory
yum install jfrog-artifactory-pro-6.y.z |
Tip |
---|
To install the latest version of Artifactory, you can run: yum install jfrog-artifactory-pro |
|
Note |
---|
title | Running Artifactory as ROOT |
---|
| If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps described in Newtablink |
---|
Text | this Knowledge Base article |
---|
URL | https://www.jfrog.com/knowledge-base/how-do-i-setup-artifactory-to-run-as-the-root-application-in-tomcat/ |
---|
| . |
Note |
---|
title | Version-specific Special Instructions |
---|
| To accommodate internal changes in Artifactory in different version upgrades, you need to perform or ensure certain changes to Artifactory's server.xml according to your target upgrade version. Note that the changes listed below are cumulative as the versions progress.
Upgrading to version 5.4.0 and above From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, JFrog Access, installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see <Host name="localhost" appBase="webapps" startStopThreads="2"/>): Code Block |
---|
...
<Engine name="Catalina" defaultHost="localhost">
<Host name="localhost" appBase="webapps" startStopThreads="2"/>
</Engine>
... |
Upgrading to version 5.6.1 and above In version 5.6.1, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate YUM clients following this upgrade, a new attribute, sendReasonPhrase was added for each Tomcat connector in the server.xml file as shown in the example below: Code Block |
---|
<Connector port="8081" sendReasonPhrase="true"/> |
Upgrading to version 5.7.0 and above From version 5.7.0, Artifactory routes requests to its Access service directly through a port, and this requires the following modification to the server.xml file Code Block |
---|
<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/> |
Upgrading to version 6.3 and above
From version 6.3, the version of the Tomcat embedded in Artifactory was upgraded. To accomodate special characters following this upgrade, the following new attributes, relaxedPathChars='[]' relaxedQueryChars='[]' were added for each Tomcat connector in the server.xml as shown in the example below: Code Block |
---|
<Service name="Catalina">
<Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/> |
Upgrading to version 6.14.0 and above From version 6.14.0, the systemd runs successfully. Prior to upgrading to this version perform the following steps: Stop Artifactory by running the following command. Ignore any errors that may arise, and allow it to run to disable the auto start by systemd. Code Block |
---|
systemctl stop artifactory.service |
Kill any running Artifactory Java process that may still be running, using the following command: Code Block |
---|
ps -ef | grep java | grep artifactory | grep tomcat |
Rename the existing /etc/opt/jfrog/artifactory/default file to the new artifactory.pid file location: Code Block |
---|
export ARTIFACTORY_PID=/var/run/artifactory.pid |
Run the new RPM installation Start Artifactory by running the following command: Code Block |
---|
systemctl start artifactory.service |
|
|
|
RPM OSS Installation
Expand |
---|
- Download the Artifactory OSS RPM Installer. The latest version can be downloaded from the
Newtablink |
---|
Text | JFrog Open Source page |
---|
URL | https://www.jfrog.com/open-source/#artifactory |
---|
| . Previous versions can be downloaded from Newtablink |
---|
Text | JFrog Bintray |
---|
URL | https://bintray.com/jfrog/artifactory-rpms/jfrog-artifactory-oss-rpm |
---|
| . - Log in as root (or use
sudo su - ). - If you have not yet done so, perform a graceful shutdown of your currently running installation
Execute the following command: Code Block |
---|
rpm -U jfrog-artifactory-oss-6.y.z.rpm |
During an upgrade of an RPM installation different files may get backed up, where the backup file is appended with either a .rpmorig or a .rpmnew extension. A .rpmorig extension means that the original file in your installation, the one that was there before performing the upgrade, was backed up before being replaced in the upgrade process. A .rpmnew extension means that the original file in your installation, was not replaced in the upgrade, and instead, the new file with the same filename was backed up. In either case, Artifactory will display a message such as: warning: /etc/opt/jfrog/artifactory/default saved as /etc/opt/jfrog/artifactory/default.rpmorig In these cases we recommend comparing the file installed once the upgrade has been completed with the backed-up file to see which best fits your needs, and using that one in the final setup. If you make any changes, you may need to restart Artifactory for the change to be applied. Upgrading Using YUMAn easy way to upgrade Artifactory from version 3.x or 4.x to the latest version is to use YUM with the Bintray Artifactory repository. The code snippets below show how to do this depending on whether your current version is below 3.6, or 3.6 and above. Expand |
---|
title | If your current version is 3.6 and above: |
---|
| Code Block |
---|
curl https://bintray.com/jfrog/artifactory-rpms/rpm -o bintray-jfrog-artifactory-rpms.repo && sudo mv bintray-jfrog-artifactory-rpms.repo /etc/yum.repos.d/
yum install jfrog-artifactory-oss-6.x.y |
Tip |
---|
To install the latest version of Artifactory, you can run: yum install jfrog-artifactory-oss |
|
Expand |
---|
title | If your current version is below 3.6: |
---|
| Code Block |
---|
curl https://bintray.com/jfrog/artifactory-rpms/rpm -o bintray-jfrog-artifactory-rpms.repo && sudo mv bintray-jfrog-artifactory-rpms.repo /etc/yum.repos.d/
yum upgrade artifactory
yum install jfrog-artifactory-oss-6.y.z |
Tip |
---|
To install the latest version of Artifactory, you can run: yum install jfrog-artifactory-oss |
|
Note |
---|
title | Running Artifactory as ROOT |
---|
| If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps described in Newtablink |
---|
Text | this Knowledge Base article |
---|
URL | https://www.jfrog.com/knowledge-base/how-do-i-setup-artifactory-to-run-as-the-root-application-in-tomcat/ |
---|
| . |
Note |
---|
title | Version-specific Special Instructions |
---|
| To accommodate internal changes in Artifactory in different version upgrades, you need to perform or ensure certain changes to Artifactory's server.xml according to your target upgrade version. Note that the changes listed below are cumulative as the versions progress. Upgrading to version 5.4.0 and above From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, JFrog Access, installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see <Host name="localhost" appBase="webapps" startStopThreads="2"/>): Code Block |
---|
...
<Engine name="Catalina" defaultHost="localhost">
<Host name="localhost" appBase="webapps" startStopThreads="2"/>
</Engine>
... |
Upgrading to version 5.6.1 and above In version 5.6.1, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate YUM clients following this upgrade, a new attribute, sendReasonPhrase was added for each Tomcat connector in the server.xml file as shown in the example below: Code Block |
---|
<Connector port="8081" sendReasonPhrase="true"/> |
Upgrading to version 5.7.0 and above From version 5.7.0, Artifactory routes requests to its Access service directly through a port, and this requires the following modification to the server.xml file Code Block |
---|
<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/> |
Upgrading from version 6.3 and above
From version 6.3, the version of the Tomcat embedded in Artifactory was upgraded. To accomodate special characters following this upgrade, the following new attributes, relaxedPathChars='[]' relaxedQueryChars='[]' were added for each Tomcat connector in the server.xml as shown in the example below: Code Block |
---|
<Service name="Catalina">
<Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/> |
|
|
Using SHA256 Checksums
From version 5.5, Artifactory natively supports SHA-256. New artifacts that are uploaded will automatically have their SHA-256 checksum calculated, however, artifacts that were already hosted in Artifactory prior to the upgrade will not have their SHA-256 checksum in the database yet.
To make full use of Artifactory's SHA-256 capabilities after upgrading to version 5.5 and above, you need to run a process that migrates Artifactory's database making sure that the record for each artifact includes its SHA-256 checksum. For full details on Artifactory's SHA-256 support and instructions on how to migrate your database, please refer to SHA-256 Support.
Upgrading from OSS to Pro
Even if you're just switching your current version of Artifactory OSS to the same version of Artifactory Pro, please follow the instructions under Upgrading to the Latest Version according to your installation type (ZIP, RPM, Debian or Docker).
Note |
---|
|
After upgrading to the latest version, make sure you provide your Artifactory installation with a license. Simply create a file called artifactory.lic, copy the license you have received from JFrog and paste it into the artifactory.lic license file, and place it in the $ARTIFACTORY_HOME/etc folder. |
Upgrading to Version 6.6 and Above
This section is only relevant for users using Build Integration and Build Info.
During the 6.6 upgrade, there will be a migration of all existing build info json files from the DB to a default artifactory-build-info repository in Artifactory.
This default artifactory-build-info repository will store all build info files uploaded to Artifactory by the different CI server plugins, such as the Artifactory Jenkins Plugin, CLI, and directly through the Build Upload REST API or Artifactory UI.
Additional information about the migration process can be found here.
Upgrading from Version 3.x
Single Package Type Repositories
Note |
---|
|
To work with version 4.x and above, you need to ensure that your repositories only contain artifacts with the same package type. A script to check this can be found on the JFrog GitHub. |
In version 3.x Artifactory supported repositories with multiple package types. You were able to upload packages with different types to the same repository and Artifactory would calculate the metadata for those packages. Nevertheless, maintaining a single package type per repository was always a best practice that optimized performance and produced a more organized repository structure in your system. From version 4.0, you need to specify a single Package Type for a repository when you create it. Artifactory will only calculate metadata for, and be recognized by the corresponding client software for artifacts of the Package Type specified for that repository. (Artifactory will not prevent you from uploading packages of a different type, however, it will not calculate metadata for those packages, and the client for the different package types will not recognize the repository).
If you currently have repositories that are configured to support multiple package types, you need to migrate them to single package type repositories, however, you may do so either before or after running the upgrade procedure.
To migrate your repositories before upgrading, please refer to Migrating to Single Package Type Repositories.
If you prefer to migrate your repositories after upgrading, or have already upgraded, please refer to Fixing Multiple Package Type Repositories.
Tip |
---|
title | Generic repositories |
---|
|
In version 4.x and 5.x, if you need a repository to hold packages of several different types, you may specify its package type to be Generic. Artifactory does not calculate metadata for Generic repositories, and effectively, they behave like a simple file system to store packages. |
Migrating to Single Package Type Repositories
To migrate a repository with multiple package types to single package type repositories, execute the following steps:
- Change the configuration of the original repository so it supports only one package type.
- For each additional packaging type needed, create a new repository with the corresponding package type
- Use the REST API or the UI to move packages from the original repository to the new one(s) created until all repositories only contain packages of the same type.
When using the REST API, make sure to include the suppressLayouts=1
query parameter in order to prevent artifact path transformations.
Note |
---|
|
If you move data to an Npm repository, make sure to include the .npm folder. This will preserve extra information that may have been stored when deploying packages using the npm client. |
Fixing Multiple Package Type Repositories
If you upgraded without migrating to single package type repositories, then Artifactory will start normally, however, repositories containing multiple package types will be randomly assigned one of the single package types from the original repository and output corresponding messages to the $ARTIFACTORY_HOME/logs/artifactory.log
file.
For example, if libs-release-local contained three different package types: RubyGems, Npm and NuGet, after upgrading, your $ARTIFACTORY_HOME/logs/artifactory.log may contain messages similar to the ones below:
Code Block |
---|
|
2015-06-28 10:10:47,656 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:42) Converting repositories to a single package type
2015-06-28 10:10:47,663 [art-init] [ERROR] (o.a.v.c.v.SingleRepoTypeConverter:155) Disabling package 'Gems' for repo 'libs-release-local' since only one packaging type is allowed!
2015-06-28 10:10:47,664 [art-init] [ERROR] (o.a.v.c.v.SingleRepoTypeConverter:155) Disabling package 'Npm' for repo 'libs-release-local' since only one packaging type is allowed!
2015-06-28 10:10:47,664 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'libs-release-local' to type NuGet
2015-06-28 10:10:47,664 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'libs-snapshot-local' to type Maven
2015-06-28 10:10:47,664 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'plugins-release-local' to type Maven
2015-06-28 10:10:47,664 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'plugins-snapshot-local' to type Maven
2015-06-28 10:10:47,665 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'ext-release-local' to type Maven
2015-06-28 10:10:47,665 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'ext-snapshot-local' to type Maven
2015-06-28 10:10:47,666 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'jcenter' to type Maven
2015-06-28 10:10:47,666 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'remote-repo' to type Maven
2015-06-28 10:10:47,668 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'libs-snapshot' to type Maven
2015-06-28 10:10:47,668 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'p2' to type P2
2015-06-28 10:10:47,668 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:56) Finished Converting repositories to a single package type |
In this example, Artifactory set the Package Type to NuGet.
To fix this condition, you can simply follow steps described above in Migrating to Single Package Type Repositories, or after you upgrade, use the packageType utility found on the JFrog Github for 4.x migrations.
Upgrading from Any Version Below v3.0
To upgrade from a version prior to 3.0, you first need to upgrade to version 3.9.x as described in Upgrading Artifactory in the Artifactory 3 documentation.
Note |
---|
|
Depending on your current version, upgrading to version 3.9.x may require you to first upgrade to an interim version. |
Downgrading Artifactory
The procedure to downgrade Artifactory may vary depending on the version you are using. For more details, please contact
Newtablink |
---|
Text | JFrog Support |
---|
URL | https://www.jfrog.com/support-service/support/ |
---|
|
.