blocks|key|1798065|text|您可以使用内部版本号，并且不会覆盖现有版本。相反，buildNumber可以包括一些错误修复/安全修复。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1798066|https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#A1000661|offset|length|1798067|如果使用的是深度，则可以使用表达式处理版本。包含buildNumber的确切版本或表达式。|1798068|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|25|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

You could work with build numbers, and you wouldn't overwrite existing versions. Instead a buildNumber could include some bugfixes/security fixes.

<a href="https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#A1000661" rel="nofollow noreferrer">https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#A1000661</a>

If you're using the depenfency, you can handle the versions with expressions. Exact version or expression which covers the buildNumber.

blocks|key|1406211|text|如果已经部署了工件而不是失败了，那么|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1406212|不应该忽视Jenkins的工件插件的部署吗？|blockquote|1406213|1406214|1406215|如果工件已经与固定版本(非-SNAPSHOT)一起部署，则作业将失败。例如，在手动作业触发器上，我想知道是否尝试使用已经发布的版本名(可能是团队中的其他人)构建和部署。|1406216|1406217|还是应该一直使用-SNAPSHOT+(在开发期间)，即使工件没有改变？|1406218|1406219|1406220|-SNAPSHOT是为开发而开发的。是的，我们通常在构建结束时推送工件，即使它没有改变，因为您更新了一个自述文件并触发了作业。|1406221|通常，快照的生存期取决于您如何配置二进制存储库(这里是Artifactory)。例如，快照可以每两周清理一次。|1406222|Manuel共享的链接还有其他有趣的定义，如|1406223|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|code-block|syntax|javascript|1406224|https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN401|offset|length|1406225|1406226|，我们是否增加了每个版本的版本，即使工件没有改变？|1406227|1406228|1406229|是的，我们增加了每个版本的版本号。我称之为释放客户会得到什么。除了一个特殊的场合，如果工件没有改变，你就不会经历释放的过程。发布通常涉及到组织中的许多人，甚至不是来自开发部门的人。一个流行的标准是使用语义版本化https://semver.org/，有时人们更喜欢使用日期进行版本。我的建议是使用semver，并在工件中有一个包含构建日期的文件。这个文件可以被工件本身用来在运行时告诉它的版本。|1406230|entityMap|0|LINK|mutability|MUTABLE|url|1|https://semver.org/^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|25|0|0|0|0|0|0|2X|J|1|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1J|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|J|3|K|5|D|7|1O|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1R|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1S|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1T|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1U|8|@]|9|@]|A|$W|X]]|$1|Y|3|Z|5|6|7|1V|8|@]|9|@$10|1W|11|1X|1|1Y]]|A|$]]|$1|12|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|13|3|14|5|D|7|20|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|23|8|@]|9|@$10|24|11|25|1|26]]|A|$]]|$1|19|3|-4|5|6|7|27|8|@]|9|@]|A|$]]]|1A|$1B|$5|1C|1D|1E|A|$1F|Z]]|1G|$5|1C|1D|1E|A|$1F|1H]]]]

<blockquote>
 Shouldn't the artifactory plugin from Jenkins just ignore the deploy
 of the artifact in case is already deployed instead of failing the
 job?
</blockquote>

The job should fail if the artifact is already deployed with a fixed version (non -SNAPSHOT). For instance on a manual job trigger, I would like to know if I tried to build and deploy using a version name that is already published (maybe by someone else in the team)

<blockquote>
 Or should we use always -SNAPSHOT (during development) even the
 artifact has not changed?
</blockquote>

-SNAPSHOT is made for development. Yes we usually push the artifact at the end of the build, even if it did not change because you updated for instance a README and the job was triggered.

Usually SNAPSHOT have a lifetime depending on how you binary repository (here Artifactory) is configured. SNAPSHOT can be cleaned every 2 weeks for instance.

The link shared by Manuel has other interesting definitions like

<pre><code>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
</code></pre>

<a href="https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN401" rel="nofollow noreferrer">https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN401</a>

<blockquote>
 Do we increase the version on every release
 even the artifact has not changed?
</blockquote>

yup we increase the version number at every release. I call release what the customer will get. Except an exceptional occasion, you wont go through the process of release if the artifact didn't change. A release usually involves a lot of people in an organization, even people that are not from Development. A popular standard is to use semantic versioning <a href="https://semver.org/" rel="nofollow noreferrer">https://semver.org/</a> Sometime people prefer to version with the date. My advice is to use semver and have a file in the artifact with the date of the build. This file could be used by the artifact itself to tell its version at runtime.

I'm trying to extend our Jenkins job (which builds the entire project) to deploy the built artifacts to our Artifactory but then I faced some problems related to the versioning of the artifacts. If I try to redeploy an artifact whose version didn't change (not a snapshot), I get an error 403 (user 'foo' needs DELETE permission) which is understandable, I should not replace an already released artifact. If the artifact version contains <code>-SNAPSHOT</code> then there are no problems, it's always uploaded. My question is: how we should approach the scenario of having locked overwriting in Artifactory? 

<ul>
<li>Shouldn't the artifactory plugin from Jenkins just ignore the deploy of the artifact in case is already deployed instead of failing the job?</li>
<li>Or should we use always -SNAPSHOT (during development) even the artifact has not changed?</li>
<li>Do we increase the version on every release even the artifact has not changed?</li>
</ul>

How to versionate artifacts on Artifactory without overwriting

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在尝试扩展Jenkins作业(它构建了整个项目)，以便将构建的工件部署到Artifactory中，但随后我遇到了与工件的版本控制有关的一些问题。如果我试图重新部署一个版本没有改变(而不是快照)的工件，我会得到一个错误403 (用户'foo‘需要删除权限)，这是可以理解的，我不应该替换已经发布的工件。如果工件版本包含...

问如何在不覆盖的情况下在Artifactory上验证工件
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在不覆盖的情况下在Artifactory上验证工件EN