【问题标题】:now getting 401 unauthorized in jenkins when deploying artifact to archiva maven repo现在在将工件部署到archiva maven repo时在jenkins中获得401未经授权
【发布时间】:2012-12-11 00:32:51
【问题描述】:

在我将 Jenkins 升级到 1.494 之前,这曾经可以工作。现在,当我使用构建升级插件将战争工件复制到快照存储库时,我在 Jenkins 中收到此错误:

    ERROR: Failed to deploy artifacts: Could not transfer artifact com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to archiva.apache.snapshots (http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer file: http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war. Return code is: 401, ReasonPhrase:Unauthorized.
org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to deploy artifacts: Could not transfer artifact com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to archiva.apache.snapshots (http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer file: http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war. Return code is: 401, ReasonPhrase:Unauthorized.
    at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:141)
    at hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:190)
    at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:173)
    at hudson.plugins.promoted_builds.Promotion$RunnerImpl.build(Promotion.java:187)
    at hudson.plugins.promoted_builds.Promotion$RunnerImpl.doRun(Promotion.java:141)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
    at hudson.model.Run.execute(Run.java:1543)
    at hudson.model.Run.run(Run.java:1489)
    at hudson.plugins.promoted_builds.Promotion.run(Promotion.java:106)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:236)
Caused by: org.sonatype.aether.deployment.DeploymentException: Failed to deploy artifacts: Could not transfer artifact com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to archiva.apache.snapshots (http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer file: http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war. Return code is: 401, ReasonPhrase:Unauthorized.
    at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:280)
    at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211)
    at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443)
    at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137)
    ... 10 more
Caused by: org.sonatype.aether.transfer.ArtifactTransferException: Could not transfer artifact com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to archiva.apache.snapshots (http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer file: http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war. Return code is: 401, ReasonPhrase:Unauthorized.
    at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:951)
    at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:941)
    at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:837)
    at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467)
    at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274)
    ... 13 more
Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war. Return code is: 401, ReasonPhrase:Unauthorized.
    at org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:613)
    at org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:509)
    at org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:490)
    at org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:470)
    at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:811)
    ... 15 more

我在 settings.xml 文件中有凭据:

<server>
      <id>snapshots</id>
      <username>deployment</username>
      <password>deployment</password>
    </server>

不知道为什么这突然停止使用 1.494。我逐渐降级到 1.491,但它仍然发生。非常沮丧。

【问题讨论】:

  • 401 是一个授权问题,所以你在正确的轨道上
  • 根据我的经验,按照马克所说的去做。
  • 我知道什么是 401 错误。问题是它开始出现在曾经有效但不再有效的项目中......

标签: maven jenkins maven-plugin archiva


【解决方案1】:

在重新创建我的 Archiva 存储库后,我错过了为部署用户提供角色 RepositoryManager。添加角色后,解决了上传工件时的401问题。

Archiva User Guide

【讨论】:

    【解决方案2】:

    感谢您跟进解决方案 Oggie。我刚刚遇到了同样的症状,并且已经克服了您的新用户修复。

    更多信息: 通过删除旧用户并使用完全相同的用户名和密码创建一个新用户,我能够使旧用户名和密码正常工作。 (虽然我一直在尝试使用相同/不同密码的新用户)。

    关于原因... 我没什么想法。我们在与 UberSVN 相同的机器上运行 Archiva,我们的 Jenkins 作为插件位于 UberSVN 中。没有对其中任何一个进行升级。然而,对服务器上的各种目录进行了许多所有权更改,尽管我看不出这些是原因,因为解决方案是简单地创建一个新用户。

    再次感谢您的帖子。

    【讨论】:

      【解决方案3】:

      我想出了如何解决这个问题,但我仍然不知道它是如何开始的。

      我在 Archiva 中创建了第三个用户,并将其设置为用户无需在第一次登录时更改密码。然后我用那个新用户更新了 Jenkins 中的 settings.xml。

      现在可以了。

      我仍然不知道为什么它停止与原始用户合作。

      感谢大家的帮助。

      【讨论】:

        【解决方案4】:

        您已经通过降级证明了自己这不是纯粹的 Jenkins 问题。由于密码位于 settings.xml 中,请尝试在 Jenkins mvn help:effective-settings 中运行它。这将为您提供运行时的确切设置以及密码是否存在。

        还可以尝试检查&lt;id&gt;snapshots&lt;/id&gt;&lt;username&gt;deployment&lt;/username&gt; 的拼写。我今天刚刚在某个地方遇到了这个错误,用户是 releases 而不是 release 并且 maven 给出了 forbidden 错误

        【讨论】:

        • +1 Clever,一个非常有用的插件,用于诊断行为不端的 Maven 构建。
        • 拼写没问题。我什至将用户名更改为管理员用户的用户名...我还使用了 help:effective-settings 来打印设置,这与我预期的一样,并且使用了正确的文件。
        • 我使用 Nexus 作为 repo 管理器,如果我使用 admin ID 进行部署,仍然需要通过添加 role 来授予它特殊权限。这意味着即使它具有管理员权限,也无法部署,除非它具有明确给出的正确权限。在我的例子中,它被称为`Nexus Deployment Role`
        • 我不得不对此投赞成票,因为在阅读它之后,我们终于从 settings.xml 中发现了一个小的拼写错误,已经被 4 人阅读,并且被认为很好。我们错了。 :) 很容易假设问题不在这里,因为我之前检查过它,因此忽略了所有相反的证据......
        • 不知何故我有 2 个名为 .m2 的文件夹,这个命令解决了我的问题,谢谢。
        【解决方案5】:

        我建议安装Config File Provider plugin,它提供了一个很好的 GUI 用于编辑配置文件的内容(例如 Maven 设置文件)

        在配置您的构建时,使用“-s”选项告诉 Maven 使用以下配置文件之一:

        mvn -s $MY_PROJECTS_MAVEN_SETTINGS ???
        

        这种方法的优点是您可以确定构建使用的是您的设置,而不是一些随机文件,它可能会从文件系统中移除。第二个好处是每个项目现在都可以轻松拥有自己的特定 Maven 设置(例如,每个项目很可能有不同的凭据)。

        【讨论】:

        • 试过了,但并没有解决最初的问题。我知道正在使用什么设置文件。
        • @Oggie 你假设你知道这些设置。根据我的经验,在 Maven 构建中使用“-s”选项是必要的,以便绝对确定。我喜欢 Pulak 的建议,即使用“帮助:有效设置插件来解决这个问题。如果您确定 Maven 使用的是预期的密码并且您仍然收到 401 错误,那么可能是服务器上的密码已更改?您是否尝试使用这些凭据登录?如果您控制 Archiva 服务器,也许您应该重置密码。
        • 我使用了 help:effective-settings,它打印出了我期望的设置。我可以控制 Archiva 服务器,实际上创建了一个新用户,它的行为仍然相同。请记住,Archiva、操作系统或项目中没有任何变化。唯一的变化是将 Jenkins.war 更新到最新版本。不管它做了什么,降级并没有解决它。
        • +1 for 根据我的经验,在 Maven 构建中使用 -s 选项是必要的,以便绝对确定
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2021-10-23
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多