如何在不覆盖的情况下对 Artifactory 上的工件进行版本控制
How to versionate artifacts on Artifactory without overwriting
我正在尝试扩展我们的 Jenkins 工作（构建整个项目）以将构建的工件部署到我们的 Artifactory，但随后我遇到了一些与工件版本控制相关的问题。如果我尝试重新部署版本未更改（不是快照）的工件，我会收到错误 403（用户 'foo' 需要 DELETE 权限），这是可以理解的，我不应该替换已经发布的工件。如果工件版本包含 -SNAPSHOT 则没有问题，它始终会上传。我的问题是：我们应该如何处理在 Artifactory 中锁定覆盖的情况？
- Jenkins 的工件插件是否应该忽略工件的部署以防万一已经部署而不是使作业失败？
- 或者我们是否应该始终使用 -SNAPSHOT（在开发过程中）即使工件没有改变？
- 即使工件没有改变，我们是否会在每次发布时都增加版本？
您可以使用内部版本号，并且不会覆盖现有版本。相反，buildNumber 可以包含一些 bugfixes/security 修复。
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#A1000661
如果您使用的是依赖项，则可以使用表达式处理版本。涵盖 buildNumber.
的确切版本或表达式
Shouldn't the artifactory plugin from Jenkins just ignore the deploy
of the artifact in case is already deployed instead of failing the
job?
如果已经使用固定版本（非快照）部署工件，则作业应该会失败。例如，在手动作业触发器上，我想知道我是否尝试使用已经发布的版本名称（可能由团队中的其他人发布）进行构建和部署
Or should we use always -SNAPSHOT (during development) even the
artifact has not changed?
-SNAPSHOT 是为开发而制作的。是的，我们通常在构建结束时推送工件，即使它没有改变，因为您更新了例如自述文件并触发了作业。
通常 SNAPSHOT 的生命周期取决于您如何配置二进制存储库（此处为 Artifactory）。例如，可以每 2 周清理一次 SNAPSHOT。
Manuel 分享的 link 还有其他有趣的定义，例如
Usually, only the most recently deployed SNAPSHOT,
for a particular version of an artifact is kept in the artifact repository.
Although the repository can be configured to maintain a rolling archive
with a number of the most recent deployments of a given artifact
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN401
Do we increase the version on every release
even the artifact has not changed?
是的，我们在每次发布时都会增加版本号。我称之为发布客户将得到的东西。除非特殊情况，否则如果工件没有更改，您将不会经历发布过程。发布通常涉及组织中的很多人，甚至是非开发人员。一个流行的标准是使用语义版本控制 https://semver.org/ 有时人们更喜欢使用日期进行版本控制。我的建议是使用 semver 并在工件中包含一个包含构建日期的文件。工件本身可以使用此文件在运行时告知其版本。
我正在尝试扩展我们的 Jenkins 工作（构建整个项目）以将构建的工件部署到我们的 Artifactory，但随后我遇到了一些与工件版本控制相关的问题。如果我尝试重新部署版本未更改（不是快照）的工件，我会收到错误 403（用户 'foo' 需要 DELETE 权限），这是可以理解的，我不应该替换已经发布的工件。如果工件版本包含 -SNAPSHOT 则没有问题，它始终会上传。我的问题是：我们应该如何处理在 Artifactory 中锁定覆盖的情况？
- Jenkins 的工件插件是否应该忽略工件的部署以防万一已经部署而不是使作业失败？
- 或者我们是否应该始终使用 -SNAPSHOT（在开发过程中）即使工件没有改变？
- 即使工件没有改变，我们是否会在每次发布时都增加版本？
您可以使用内部版本号，并且不会覆盖现有版本。相反，buildNumber 可以包含一些 bugfixes/security 修复。
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#A1000661
如果您使用的是依赖项，则可以使用表达式处理版本。涵盖 buildNumber.
的确切版本或表达式Shouldn't the artifactory plugin from Jenkins just ignore the deploy of the artifact in case is already deployed instead of failing the job?
如果已经使用固定版本（非快照）部署工件，则作业应该会失败。例如，在手动作业触发器上，我想知道我是否尝试使用已经发布的版本名称（可能由团队中的其他人发布）进行构建和部署
Or should we use always -SNAPSHOT (during development) even the artifact has not changed?
-SNAPSHOT 是为开发而制作的。是的，我们通常在构建结束时推送工件，即使它没有改变，因为您更新了例如自述文件并触发了作业。
通常 SNAPSHOT 的生命周期取决于您如何配置二进制存储库（此处为 Artifactory）。例如，可以每 2 周清理一次 SNAPSHOT。
Manuel 分享的 link 还有其他有趣的定义，例如
Usually, only the most recently deployed SNAPSHOT,
for a particular version of an artifact is kept in the artifact repository.
Although the repository can be configured to maintain a rolling archive
with a number of the most recent deployments of a given artifact
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN401
Do we increase the version on every release even the artifact has not changed?
是的，我们在每次发布时都会增加版本号。我称之为发布客户将得到的东西。除非特殊情况，否则如果工件没有更改，您将不会经历发布过程。发布通常涉及组织中的很多人，甚至是非开发人员。一个流行的标准是使用语义版本控制 https://semver.org/ 有时人们更喜欢使用日期进行版本控制。我的建议是使用 semver 并在工件中包含一个包含构建日期的文件。工件本身可以使用此文件在运行时告知其版本。