【问题标题】:How to ensure that maven doesn't accidentally deploy to release repoisitory?如何确保 maven 不会意外部署以发布存储库?
【发布时间】:2022-01-07 07:10:45
【问题描述】:

所以我正在为一个在他的构建脚本中使用 mvn deploy 语句的客户工作,我试图找出一种方法来防止 maven 意外覆盖 Artifactory 的发布存储库中的工件,例如,如果开发人员忘记了在他的功能分支上用 -SNAPSHOT 标记他的 POM 版本。

我不是maven专家,但是我看到了一些建议,比如使用某些maven插件,但是这些插件的使用必须在POM中配置然后我回到我开始的地方,如果忘记了怎么办在功能分支上?必须有一个既定的方法来确保不会将来自功能分支的工件部署到发布存储库中,并且不会将来自发布分支的工件意外部署到快照存储库中。

我能想到并且也有人建议的一种方法是,简单地禁止在 Artifactory 中的发布存储库上重新部署,但是如果我有一个在创建 PR 后触发的验证构建,然后另一个 CI 构建触发并且尝试重新部署?

还有其他好方法可以实现吗?

【问题讨论】:

  • 应始终防止重新部署发布存储库,因为发布是不可变的。为什么需要在功能分支中更改为-SNAPSHOTmain 分支应该已经是-SNAPSHOT,所以每个特性分支上已经有-SNAPSHOT...发布应该通过 Jenkins 触发,它将版本更改为非 SNAPSHOT`s...这将解决问题。 ..
  • 好吧,我很困惑,我通常不使用 maven。您知道描述整个工作流程的任何好的资源吗?

标签: maven artifactory maven-plugin mvn-repo


【解决方案1】:

一种解决方案是确保特定用户/组拥有删除权限。

在此处查看更多信息:https://www.jfrog.com/confluence/display/JFROG/Permissions#Permissions-RepositoryPermissions

注意:我有一段时间没有使用 Artifactory,但根据文档,这是有道理的。

【讨论】:

  • 是的,我们也有这种机制,但这只会影响实际用户,而不影响我运行构建系统的帐户。此帐户应具有覆盖权限
  • 另一种解决方案是为重复版本添加后缀,例如,-X。 repo 只会指向最新的,或者您可以指定后缀是版本。我知道这是可能的,因为我们在过去的位置上做过,但忘记了如何完成它。
  • 代替我上一条评论中的解决方案,您始终可以向工件添加时间戳,例如 <finalName>${project.artifactId}-${project.version}-${maven.build.timestamp}</finalName>。您还可以使用buildnumber-maven-plugin 创建带有数字的属性。
  • 我会检查 buildnumber-maven-plugin,谢谢
  • 不客气。让我知道它是如何工作的,如果您需要更多帮助,请勾选或发表评论!
猜你喜欢
  • 2012-10-21
  • 1970-01-01
  • 2011-05-05
  • 2020-12-08
  • 2017-08-10
  • 2012-03-20
  • 1970-01-01
  • 2023-03-14
  • 2012-09-05
相关资源
最近更新 更多