升级Artifactory

概述

升级Artifactory的过程取决于您的安装类型。我们强烈建议您在继续升级之前通读此页面。在以下安装类型的专用页面中提供了详细的升级说明:

ZIP文件
RPM
Debian
码头工人

此外，在每种安装类型中，如果您是从旧版本的Artifactory升级，则说明可能略有不同。

继续之前

升级前

我们强烈建议您采取以下操作，以确保在升级过程中遇到任何问题时可以回滚系统:

做一个完整的系统出口在开始升级过程之前。如果在任何时候决定回滚到当前版本，可以使用导出完整地再现当前系统。
备份数据库。
如果您使用的是关系数据库，请确保在您的db.properties文件具有修改数据库架构的权限

在继续之前，有几点需要解决:

JDK版本
从4.0版本开始，Artifactory需要JDK 8。如果当前版本是v3。x，在升级到5号工艺品之前。请确保安装JDK 8并更新您的JAVA_HOME环境变量指向JDK 8的安装。详情请参阅系统需求。
具有多种包类型的存储库
从4.0版本开始，Artifactory将只对单个包类型存储库的相应客户端进行索引和处理。如果当前版本是3。X和安装包含支持多种包类型的存储库，您需要将它们迁移到单个包类型的存储库。您可以在升级之前或之后这样做。有关详情，请参阅单一包类型存储库。
'斜杠'字符编码用于NPM构建
NPM对'斜杠'字符编码的处理已从artifactory.system.properties存档到catalina.propertiesTomcat的文件。详情请参阅Npm作用域包。

页面内容

了解更多

升级企业高可用性集群

升级Artifactory Enterprise / HA

升级人工HA有不同的说明

在升级HA集群时，升级每个节点的过程类似于升级单个实例(非HA)安装，但是，节点需要额外的操作才能作为高可用性集群运行。

如果您正在升级人工高可用性集群，请参考升级企业高可用性集群。

升级到最新版本

server.xml文件默认值从Artifactory 6.10更改

从6.10版本开始，n新的Artifactory安装将不包括美国连接器在Artifactory的Tomcat server.xml文件中(即$ARTIFACTORY_HOME/ Tomcat /conf/server.xml下)。

要使用AJP连接器应该手动添加到server.xml文件下<服务名称=“卡特琳娜”>。

升级后的人工环境将保持不变，提供server.xml文件被复制。

请注意：美国连接器支持将在Artifactory的下一个主要版本(7.0)中删除。

从版本4升级。X或5.x到最新版本是一个简单的过程。请参考以下章节，了解您的安装类型的具体说明。

从6.14之前的任何版本升级到6.14以上的任何版本在运行升级过程时需要root权限。升级版本6.14后不需要这个。

压缩安装

升级ZIP安装…

解压缩Artifactory发行版归档文件。
如果您还没有这样做，请正常关闭当前正在运行的安装。
如果ARTIFACTORY_HOME美元/ / conf / tomcat server.xml已被修改，保存在临时位置。
根据以下条件将文件备份到临时位置:
1. 在所有情况下，备份美元ARTIFACTORY_HOME / bin /工件ory.default
2. 如果Artifactory配置为使用非Derby的数据库，则备份ARTIFACTORY_HOME美元JDBC / tomcat / lib / < >司机。
从您的文件中删除以下文件和文件夹ARTIFACTORY_HOME美元文件夹:
- webapps / artifactory.war
- webapps /访问。War(只有当你的当前版本是5.4.0或更高版本时才会出现)访问服务）
- tomcat
- 箱子
- misc
将删除的文件和文件夹替换为新解压缩版本中的相应文件和文件夹。
存储在临时位置的任何文件现在都应该返回到新安装下的原始位置。

在Tomcat中作为ROOT应用程序运行Artifactory

如果您已经将Artifactory配置为在Tomcat中作为ROOT应用程序运行，那么在继续之前，您需要遵循中描述的步骤这篇知识库文章。
特定于版本的特殊说明
为了适应不同版本升级中Artifactory的内部更改，您需要根据您的目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级到5.4.0或更高版本

从5.4.0版本开始，Artifactory对访问令牌的管理被转移到一个单独的服务中，JFrog访问作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您正在使用以前安装中的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):
… …
升级到5.6.1及以上版本

在5.6.1版本中，升级了Artifactory中嵌入的Tomcat版本。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase是为每一个server.xml文件中的Tomcat连接器，如下例所示:
升级到5.7.0或更高版本

从5.7.0版本开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改
升级到6.3或更高版本

从版本6.3开始，Artifactory中嵌入的Tomcat版本得到了升级。为了适应此升级后的特殊字符，以下新属性:relaxedPathChars =“[]”relaxedQueryChars =“[]”为server.xml中的每个Tomcat连接器添加的，如下面的示例所示:
<服务名称="Catalina"> <连接器端口="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>
如果您将Artifactory作为服务安装，那么现在需要运行该服务
1. 对于Linux服务，浏览到美元ARTIFACTORY_HOME / bin并执行以下命令作为根：$ARTIFACTORY_HOME/bin/installService.sh [USER [GROUP]]
2. 对于Windows服务，浏览到%ARTIFACTORY_HOME%\bin。首先运行以下命令卸载服务uninstallService.bat，然后运行installService.bat。您现在可以通过Windows UI运行该服务，也可以按照运行Artifactory。

Debian安装

升级Debian安装…

以root身份登录(或使用Sudo su -）.
如果您还没有这样做，请正常关闭当前正在运行的安装
执行如下命令:
```
DPKG -i $jfrog-artifactory--6.y.z.deb
```

管理配置文件

升级时Debian安装升级过程会覆盖以下配置文件集:

system.properties
config . xml
默认的
logback.xml
mimetypes.xml
所有档案opt / jfrog / artifactory / misc
所有档案opt / jfrog / artifactory / webapps

如果这些文件中的任何一个被修改，将自动创建一个备份文件，并在升级日志中发出通知。如果需要恢复配置更改，可以从创建的备份中恢复。

以ROOT身份运行Artifactory

如果您已将Artifactory配置为在Tomcat中作为ROOT应用程序运行，在继续之前，您需要遵循中描述的步骤这篇知识库文章。

特定于版本的特殊说明

为了适应不同版本升级中Artifactory的内部更改，您需要根据您的目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级到5.4.0或更高版本

从5.4.0版本开始，Artifactory对访问令牌的管理被转移到一个单独的服务中，JFrog访问作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您正在使用以前安装中的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

…  …

升级到5.6.1及以上版本

在5.6.1版本中，升级了Artifactory中嵌入的Tomcat版本。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase是为每一个server.xml文件中的Tomcat连接器，如下例所示:

升级到5.7.0或更高版本

从5.7.0版本开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

升级到6.3或更高版本

从6.3版开始，Artifactory中嵌入的Tomcat版本升级了

<服务名称="Catalina"> <连接器端口="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>

升级到6.14.0及以上版本

从6.14.0版本开始，systemd运行成功。在升级到此版本之前，请执行以下步骤:

运行以下命令停止Artifactory。
忽略任何可能出现的错误，并允许它运行以禁用systemd自动启动。
```
Systemctl停止artifactory.service
```
使用以下命令杀死任何可能仍在运行的人工Java进程:
```
Ps -ef | grep Java | grep artifactory | grep tomcat
```
将现有的/etc/opt/jfrog/artifactory/default文件重命名为新的artifactory。Pid文件位置:
```
出口ARTIFACTORY_PID = / var /跑步/ artifactory.pid
```
运行新的Debian安装
运行如下命令启动Artifactory:
```
Systemctl启动artifactory.service
```

升级Debian OSS到Pro

为了确保在升级到Pro后所有数据都保留在Artifactory中(假设您使用默认的DB)，请遵循以下步骤:

对当前正在运行的安装执行安全关闭。
执行$ARTIFACTORY_HOME/data文件夹的备份。
删除OSS安装。
```
Apt-get - remove(青蛙-人造-丢失)
```
下载并安装Pro包。
```
DPKG -i $jfrog-artifactory-pro-.deb)
```
将“data”备份文件夹导入到新的安装位置。
```
美元ARTIFACTORY_HOME /数据
```
Artifactory开始。
```
美元ARTIFACTORY_HOME /数据
```

码头工人安装

升级Docker安装…

为了在不同版本之间保持数据和配置，在升级Artifactory Docker映像时，需要使用如下所述的外部挂载卷管理数据持久性。

要升级Artifactory Docker镜像，请执行以下步骤:

停止当前容器
使用相同的数据和配置启动具有新版本的容器
移除旧容器

下面的示例显示了将Artifactory从v5.0.0升级到v5.1.0的过程。

$ #停止当前正在运行的容器$ docker Stop artifactory-5.0.0 $ #从新版本镜像启动新容器$ docker run -d——name artifactory-5.1.0——volume -from=artifactory-5.0.0 -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:5.1.0 $ #删除旧容器$ docker rm artifactory-5.0.0

一旦这些命令成功完成，您就可以运行新版本(在上面的示例中为5.1.0)，其中包含已删除的旧版本中的数据和配置。

以ROOT身份运行Artifactory

如果您已将Artifactory配置为在Tomcat中作为ROOT应用程序运行，您需要遵循中描述的步骤这篇知识库文章。

特定于版本的特殊说明

为了适应不同版本升级中Artifactory的内部更改，您需要根据您的目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级到5.4.0或更高版本

从5.4.0版本开始，Artifactory对访问令牌的管理被转移到一个单独的服务中，JFrog访问作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您正在使用以前安装中的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

…  …

升级到5.6.1及以上版本

在5.6.1版本中，升级了Artifactory中嵌入的Tomcat版本。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase是为每一个server.xml文件中的Tomcat连接器，如下例所示:

升级到5.7.0或更高版本

从5.7.0版本开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

从6.3及以上版本升级

从版本6.3开始，Artifactory中嵌入的Tomcat版本得到了升级。为了适应此升级后的特殊字符，以下新属性:relaxedPathChars =“[]”relaxedQueryChars =“[]”为server.xml中的每个Tomcat连接器添加的，如下面的示例所示:

<服务名称="Catalina"> <连接器端口="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>

RPM的安装

升级RPM安装…

确保从v3.6或更高版本升级

作为RPM安装运行时，只能升级到v5。如果您当前的版本是3.6或更高版本。如果有必要，首先将当前版本升级到3.6，然后再升级到v5。x。

如果您尝试升级3.6以下的版本，请使用rpm——力你可能最终会删除你所有的数据。

下载Artifactory Pro RPM安装程序。最新版本可从JFrog Artifactory Pro下载页面。以前的版本可以从JFrog Bintray。
以root身份登录(或使用Sudo su -）.
如果您还没有这样做，请正常关闭当前正在运行的安装

执行如下命令:

jfrog-artifactory-pro . 6.y.z.rpm

从Artifactory OSS切换到Pro

如果你只是用相同的版本号从Artifactory切换过来，你需要在命令后面加上——force——nodeps，如下所示:

jfrog-artifactory-pro . 6.y.z.rpm--force --nodeps

在RPM安装的升级过程中，可能会备份不同的文件，其中备份文件会附加一个.rpmorig或者一个.rpmnew扩展。

一个.rpmorig扩展意味着安装中的原始文件，即在执行升级之前存在的文件，在升级过程中被替换之前进行了备份。

一个.rpmnew扩展名表示安装中的原始文件是不在升级中替换，取而代之的是备份具有相同文件名的新文件。

在这两种情况下，Artifactory都将显示如下消息:

警告:/etc/opt/jfrog/artifactory/default保存为/etc/opt/jfrog/artifactory/default.rpmorig

在这些情况下，我们建议将升级完成后安装的文件与备份文件进行比较，看看哪个最适合您的需求，并在最终设置中使用该文件。

如果您进行了任何更改，您可能需要重新启动Artifactory以应用更改。

使用YUM升级

从版本3升级Artifactory的简单方法。X或4。升级到最新版本是使用YUM和Bintray Artifactory存储库。下面的代码片段显示了如何根据当前版本是低于3.6还是高于3.6来执行此操作。

升级人工HA集群?

如果您正在升级Artifactory HA集群，并且正在使用比版本更旧的版本运行5.4.6，你应该复习一下说明升级企业高可用性集群在升级之前。

如果您当前的版本是3.6及以上:

Curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpm。Repo && sudo mv bintray-jfrog-artifactory-pro-rpm。回购/etc/yum.repos.yum install jfrog-artifactory-pro . 6.y.z

要安装最新版本的Artifactory，您可以运行:

Yum安装jfrog-artifactory-pro

如果当前版本低于3.6:

Curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpm。Repo && sudo mv bintray-jfrog-artifactory-pro-rpm。回购/etc/yum.repos.yum install jfrog-artifactory-pro . 6.y.z

要安装最新版本的Artifactory，您可以运行:

Yum安装jfrog-artifactory-pro

以ROOT身份运行Artifactory

如果您已将Artifactory配置为在Tomcat中作为ROOT应用程序运行，在继续之前，您需要遵循中描述的步骤这篇知识库文章。

特定于版本的特殊说明

为了适应不同版本升级中Artifactory的内部更改，您需要根据您的目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级到5.4.0或更高版本

从5.4.0版本开始，Artifactory对访问令牌的管理被转移到一个单独的服务中，JFrog访问作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您正在使用以前安装中的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

…  …

升级到5.6.1及以上版本

在5.6.1版本中，升级了Artifactory中嵌入的Tomcat版本。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase是为每一个server.xml文件中的Tomcat连接器，如下例所示:

升级到5.7.0或更高版本

从5.7.0版本开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

升级到6.3或更高版本

从版本6.3开始，Artifactory中嵌入的Tomcat版本得到了升级。为了适应此升级后的特殊字符，以下新属性:relaxedPathChars =“[]”relaxedQueryChars =“[]”为server.xml中的每个Tomcat连接器添加的，如下面的示例所示:

<服务名称="Catalina"> <连接器端口="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>

升级到6.14.0及以上版本

从6.14.0版本开始，systemd运行成功。在升级到此版本之前，请执行以下步骤:

运行以下命令停止Artifactory。
忽略任何可能出现的错误，并允许它运行以禁用systemd自动启动。
```
Systemctl停止artifactory.service
```
使用以下命令杀死任何可能仍在运行的人工Java进程:
```
Ps -ef | grep Java | grep artifactory | grep tomcat
```
将现有的/etc/opt/jfrog/artifactory/default文件重命名为新的artifactory。Pid文件位置:
```
出口ARTIFACTORY_PID = / var /跑步/ artifactory.pid
```
运行新的RPM安装
运行如下命令启动Artifactory:
```
Systemctl启动artifactory.service
```

RPM网管安装

点击这里展开…

下载人工OSS RPM安装程序。最新版本可从JFrog开源页面。以前的版本可以从JFrog Bintray。
以root身份登录(或使用Sudo su -）.
如果您还没有这样做，请正常关闭当前正在运行的安装
执行如下命令:
```
- jfrog-artifactory-oss-6.y.z.rpm
```

在RPM安装的升级过程中，可能会备份不同的文件，其中备份文件会附加一个.rpmorig或者一个.rpmnew扩展。

一个.rpmorig扩展意味着安装中的原始文件，即在执行升级之前存在的文件，在升级过程中被替换之前进行了备份。

一个.rpmnew扩展名表示安装中的原始文件是不在升级中替换，取而代之的是备份具有相同文件名的新文件。

在这两种情况下，Artifactory都将显示如下消息:

警告:/etc/opt/jfrog/artifactory/default保存为/etc/opt/jfrog/artifactory/default.rpmorig

在这些情况下，我们建议将升级完成后安装的文件与备份文件进行比较，看看哪个最适合您的需求，并在最终设置中使用该文件。

如果您进行了任何更改，您可能需要重新启动Artifactory以应用更改。

使用YUM升级

从版本3升级Artifactory的简单方法。X或4。升级到最新版本是使用YUM和Bintray Artifactory存储库。下面的代码片段显示了如何根据当前版本是低于3.6还是高于3.6来执行此操作。

如果您当前的版本是3.6及以上:

Curl https://bintray.com/jfrog/artifactory-rpms/rpm -o bintray-jfrog-artifactory-rpm。Repo && sudo mv bintray-jfrog-artifactory-rpm。回购/etc/yum.repos.安装jfrog-artifactory-oss-6.x.y

要安装最新版本的Artifactory，您可以运行:

Yum安装jfrog-artifactory-oss

如果当前版本低于3.6:

Curl https://bintray.com/jfrog/artifactory-rpms/rpm -o bintray-jfrog-artifactory-rpm。Repo && sudo mv bintray-jfrog-artifactory-rpm。回购/etc/yum.repos.yum install jfrog-artifactory-oss-6.y.z

要安装最新版本的Artifactory，您可以运行:

Yum安装jfrog-artifactory-oss

以ROOT身份运行Artifactory

如果您已将Artifactory配置为在Tomcat中作为ROOT应用程序运行，在继续之前，您需要遵循中描述的步骤这篇知识库文章。

特定于版本的特殊说明

为了适应不同版本升级中Artifactory的内部更改，您需要根据您的目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级到5.4.0或更高版本

从5.4.0版本开始，Artifactory对访问令牌的管理被转移到一个单独的服务中，JFrog访问作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您正在使用以前安装中的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

…  …

升级到5.6.1及以上版本

在5.6.1版本中，升级了Artifactory中嵌入的Tomcat版本。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase是为每一个server.xml文件中的Tomcat连接器，如下例所示:

升级到5.7.0或更高版本

从5.7.0版本开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

从6.3及以上版本升级

从版本6.3开始，Artifactory中嵌入的Tomcat版本得到了升级。为了适应此升级后的特殊字符，以下新属性:relaxedPathChars =“[]”relaxedQueryChars =“[]”为server.xml中的每个Tomcat连接器添加的，如下面的示例所示:

<服务名称="Catalina"> <连接器端口="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>

使用SHA256校验和

从5.5版本开始，Artifactory原生支持SHA-256。上传的新工件将自动计算其SHA-256校验和，但是，在升级之前已经在Artifactory中托管的工件在数据库中还没有其SHA-256校验和。

为了在升级到5.5及以上版本后充分利用Artifactory的SHA-256功能，您需要运行一个迁移Artifactory数据库的进程，以确保每个工件的记录包含其SHA-256校验和。有关Artifactory的SHA-256支持的详细信息以及如何迁移数据库的说明，请参考sha - 256支持。

从OSS升级到Pro

即使您只是将当前版本的Artifactory OSS切换到相同版本的Artifactory Pro，也请遵循下面的说明升级到最新版本根据您的安装类型(ZIP, RPM, Debian或Docker)。

添加您的许可证

后升级到最新版本，确保您为Artifactory安装提供了许可证。只需创建一个名为artifactory.lic,复制您从JFrog收到的许可证，并将其粘贴到artifactory.licLicense文件，并将其放入$ ARTIFACTORY_HOME /等文件夹中。

升级到6.6及以上版本

本节仅与使用构建集成和构建信息。

在6.6升级期间，将会有一个迁移所有现有的构建信息json文件将数据库设置为默认值artifactory-build-infoArtifactory中的存储库。

这个默认artifactory-build-info存储库将存储通过不同的CI服务器插件上传到Artifactory的所有构建信息文件，例如Artifactory Jenkins Plugin, CLI，或者直接通过build Upload REST API或Artifactory UI。

可以找到有关迁移过程的其他信息在这里。

从版本3.x升级

单一包类型存储库

单包类型

要使用版本4。X及以上版本，您需要确保您的存储库只包含具有相同包类型的工件。可以在JFrog GitHub。

在版本3中。x Artifactory支持具有多种包类型的存储库。您可以将不同类型的包上传到同一个存储库，Artifactory将计算这些包的元数据。尽管如此，维护每个存储库的单一包类型始终是优化性能并在系统中产生更有组织的存储库结构的最佳实践。从4.0版本开始，您需要指定一个包类型为存储库创建时创建的。Artifactory只会为工件计算元数据，并被相应的客户端软件识别为工件包类型为该存储库指定的。(Artifactory不会阻止您上传不同类型的包，但是，它不会计算这些包的元数据，并且不同包类型的客户机将无法识别存储库)。

如果您当前的存储库被配置为支持多种包类型，那么您需要将它们迁移到单个包类型的存储库，但是，您可以在运行升级过程之前或之后这样做。

要在升级之前迁移存储库，请参考迁移到单一包类型存储库。

如果您希望在升级后迁移存储库，或者已经升级，请参考修复多个包类型存储库。

通用存储库

在版本4中。X和5。如果您需要一个存储库来保存几种不同类型的包，您可以指定它的包类型为通用的。Artifactory不计算通用存储库的元数据，并且有效地，它们的行为就像一个简单的文件系统来存储包。

迁移到单一包类型存储库

要将包含多个包类型的存储库迁移到单个包类型的存储库，请执行以下步骤:

更改原始存储库的配置，使其只支持一种包类型。
对于所需的每个附加打包类型，创建一个具有相应包类型的新存储库
使用REST API或UI将包从原始存储库移动到创建的新存储库，直到所有存储库只包含相同类型的包。
在使用REST API时，请确保包含suppressLayouts = 1查询参数，以防止工件路径转换。

Npm存储库

如果您将数据移动到Npm存储库，请确保包含。npm文件夹中。这将保留在使用npm客户端部署包时可能存储的额外信息。

修复多个包类型存储库

如果您在没有迁移到单个包类型存储库的情况下进行了升级，那么Artifactory将正常启动，但是，包含多个包类型的存储库将正常启动随机从原始存储库中分配单个包类型之一，并将相应的消息输出到美元ARTIFACTORY_HOME /日志/ artifactory.log文件。

例如，如果lib -release-local包含三个不同的包类型:RubyGems、Npm和NuGet，那么在升级之后，你的美元ARTIFACTORY_HOME /日志/ artifactory.log可能包含与以下类似的消息:

2015-06-28 10:10:47,663 [art-init] [ERROR] (o.a.v.c.v.SingleRepoTypeConverter:155)在仓库'lib -release-local'中禁用包'Gems'，因为只允许一种打包类型!2015-06-28 10:10:47,664 [art-init] [ERROR] (o.a.v.c.v.SingleRepoTypeConverter:155)禁用lib -release-local的Npm包，因为只允许一种包类型!2015-06-28 10:10:47 . 664 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'lib -release-local'类型为NuGet 2015-06-28 10:10:47 . 664 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'lib -快照-local'类型为Maven 2015-06-28 10:10:47 . 664 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'plugins-release-local'类型为Maven 2015-06-28 10:10:47 . 664 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'plugins-快照-local'为Maven类型2015-06-28 10:10:47,665 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'ext-release-local'为Maven类型2015-06-28 10:10:47,666 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'ext-快照-local'为Maven类型2015-06-28 10:10:47,666 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'jcenter'为Maven类型2015-06-28 10:10:47,666 [art-init] [INFO](o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'远程-repo'为Maven类型2015-06-28 10:10:47,668 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'lib -snapshot'为Maven类型2015-06-28 10:10:47,668 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'p2'为p2类型2015-06-28 10:10:47,668 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:56)完成将存储库转换为单一包类型

在本例中，Artifactory设置包类型NuGet。

要解决这个问题，您可以简单地按照上面在迁移到单一包类型存储库，或在升级后使用packageType实用程序可以在JFrog Github上找到。x迁移。

从v3.0以下的任何版本升级

要从3.0之前的版本升级，首先需要升级到3.9版本。X，如在Artifactory 3文档中升级Artifactory。

临时版本

根据您当前的版本，升级到3.9版本。X可能要求您首先升级到临时版本。

下调Artifactory

降级Artifactory的过程可能因您使用的版本而异。欲知详情，请联络JFrog支持。