【问题标题】:How to avoid "Updates were rejected because the remote contains work" during release with maven release-plugin and git?如何在使用 maven release-plugin 和 git 发布期间避免“更新被拒绝,因为远程包含工作”?
【发布时间】:2016-11-08 07:04:32
【问题描述】:

我们最近从 SVN 迁移到了 git。除了在 git 上发布的其他(意外)问题之外,我想知道如何处理以下问题:

当我在 Jenkins 上启动发布运行并且一些开发人员(意外)在发布的第一阶段推送时,发布构建失败并出现以下错误:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on project xyz: Unable to commit files
[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR] To ssh://[some-ip]/home/git/xyz
[ERROR] ! [rejected]        release/xyz-6.10 -> release/xyz-6.10 (fetch first)
[ERROR] error: failed to push some refs to 'ssh://[some-ip]/home/git/xyz'
[ERROR] hint: Updates were rejected because the remote contains work that you do
[ERROR] hint: not have locally. This is usually caused by another repository pushing
[ERROR] hint: to the same ref. You may want to first integrate the remote changes
[ERROR] hint: (e.g., 'git pull ...') before pushing again.
[ERROR] hint: See the 'Note about fast-forwards' in 'git push --help' for details.
[ERROR] -> [Help 1]

Jenkins 用于启动发布构建的 maven 命令是(我们在 Windows 上构建,因此很遗憾,由于 git add 上的命令行太长,包括所有修改后的 pom.xml,我们不得不激活 -DautoVersionSubmodules) :

mvn -B -DdevelopmentVersion=xyz-6.10.0-rc3-SNAPSHOT -DreleaseVersion=xyz-6.10.0-rc2 -Dtag=xyz-6.10.0-rc2 -Dresume=false -e -Dgoals=deploy -DautoVersionSubmodules=true -DcommitByProject=true -P[some-profiles] -T1C release:prepare release:perform -Darguments=-T1C

有没有一种简单的方法可以阻止其他用户推送(但允许 Jenkins 推送!)?或任何其他稳定的工作 - 或最佳实践?

使用的版本:

  • Maven 3.3.9
  • Maven 发布插件 2.5.3
  • Git 2.8.1
  • 詹金斯 1.629
  • Jenkins Maven Release Plug-in Plug-in 0.14.0
  • Windows 10

提前感谢您的帮助。

【问题讨论】:

  • 我可以请投反对票的人留言,告诉我我应该在这个问题上改进什么或在新问题上做得更好吗?当他们只是被否决而没有任何评论时,提出问题并不令人鼓舞。谢谢!
  • 我面临同样的问题,除了当我执行发布时没有人推送到 repo。是否还有其他可能导致此问题的原因?

标签: git maven jenkins maven-3 maven-release-plugin


【解决方案1】:

我希望您同意发布失败是正确的。在这种情况下,修复不是一个大问题:更新项目并发布另一个版本。 解决此问题的最简单方法是:沟通 :) 只需通知同事您计划发布此版本即可。 我听说过的另一个解决方案是:先创建一个分支,然后从这个分支发布。没有人会改变分支的内容,所以这应该是一个安全的解决方案,但它需要额外的工作。是否值得由您决定。大多数时候不是。

【讨论】:

  • 我希望我的问题尽可能清楚。我的问题不是构建失败,而是我正在寻找一个失败证明的解决方案来避免这种情况。因为我假设那里有许多公司和组织使用相同的设置,所以我期待最佳实践来避免这个错误。当然,沟通应该有所帮助。但正如我所说,我正在寻找一种始终有效的解决方案。您的回答根本没有帮助我,在我看来,否决投票是不合理的!
  • 然后在发布前进行分支(如前所述)
  • 分支可能有意义。但至少你会恢复你的反对票吗?我认为这是一个合理的问题,要求最好的方法来做到这一点。我从不抱怨错误是错误的或错误的。谢谢罗伯特。
猜你喜欢
  • 2022-01-08
  • 2020-08-07
  • 2013-08-22
  • 2018-08-16
  • 2021-07-30
  • 1970-01-01
相关资源
最近更新 更多