5

This used to work before I upgraded Jenkins to 1.494. Now I get this error in Jenkins when using the build promotion plugin to copy the war artifact to the snapshot repo:

    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

I have the creds in the settings.xml file:

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

Not sure why this all of a sudden stopped working with 1.494. I downgraded incrementally to 1.491 and it still happened. Very frustrating.

Oggie
  • 387
  • 2
  • 5
  • 15

6 Answers6

14

You already proved yourself that this is not a pure Jenkins issue by downgrading. Since the password lies in settings.xml, try running this from within Jenkins mvn help:effective-settings. This would give you what exactly the settings are, at run time and whether the password is in there.

Also try checking the spelling for your <id>snapshots</id> and <username>deployment</username>. I just hit this error somewhere today, where a user was releases instead of release and maven was giving forbidden errors

Pulak Agrawal
  • 2,481
  • 4
  • 25
  • 49
  • 1
    +1 Clever, a very useful plugin for diagnosing a mis-behaving Maven build. – Mark O'Connor Dec 26 '12 at 10:52
  • Spelling is all fine. I even changed the username to that of the admin user... I also used the help:effective-settings to print out the settings and it's as I was expecting and is using the correct file. – Oggie Dec 29 '12 at 19:59
  • I use Nexus as a repo manager and if I use the `admin` ID to deploy,it still needs to be given special permissions by adding a `role` to it. Meaning even when it has admin rights, it won't be able to deploy unless it has the right permission to do so given explicitly. In my case its called ` **Nexus Deployment Role** ` – Pulak Agrawal Jan 02 '13 at 04:54
  • I had to vote up this because after reading it we finally found small spelling error from settings.xml that had been read through by 4 people and it was considered fine. We were wrong. :) It is very easy to just assume that problem is not here because I checked it before and thus ignore all the evidence that says otherwise... – Panu Feb 18 '14 at 10:42
  • I somehow had 2 folders named .m2, this command solved my issue, thanks. – coding_idiot Feb 28 '14 at 21:12
  • glad it could help someone – Pulak Agrawal Mar 22 '14 at 13:53
3

I would suggest installing the Config File Provider plugin, which provides a nice GUI for editing the contents of your configuration files (Such as the Maven settings file)

When configuring your build use the "-s" option to tell Maven to use one of these configuration files:

mvn -s $MY_PROJECTS_MAVEN_SETTINGS ???

The advantage of this approach is that you are sure the build is using your settings and not some random file it might be taking off the file system. The second benefit is that each project can now easily have their own specific Maven settings (For example each project will most likely have different credentials).

Mark O'Connor
  • 76,015
  • 10
  • 139
  • 185
  • Tried that, but it didn't solve the initial problem. I know what settings file is being used. – Oggie Dec 29 '12 at 20:00
  • 1
    @Oggie You assume you know the settings. Using the "-s" option in my experience is necessary in a Maven build in order to be absolutely sure. I love Pulak's suggestion of using the "help:effective-settings plugin to troubleshoot this problem. If you're certain Maven is using the expected password and you're still getting a 401 error then perhaps the password has been changed on the server? Have you tried to login with these credentials? If you control the Archiva server, perhaps you should reset your password. – Mark O'Connor Dec 30 '12 at 00:32
  • I used help:effective-settings and it printed out the settings I was expecting. I have control over the Archiva server and actually created a new user and it is still behaving the same way. Remember, nothing changed in Archiva, the OS, or the project. The only change was updating the Jenkins.war to the latest. And whatever it did, downgrading did not fix it. – Oggie Dec 30 '12 at 03:03
  • +1 for **Using the -s option in my experience is necessary in a Maven build in order to be absolutely sure** – Pulak Agrawal Jan 02 '13 at 04:57
2

I figured out how to get past the problem, but I still don't know how it happened to begin with.

I created a 3rd user in Archiva, and set it so the user didn't have to change their password on 1st login. I then updated the settings.xml in Jenkins with that new user.

It now works.

I still don't know why it stopped working with the original user though.

Thanks to everyone for their help.

Oggie
  • 387
  • 2
  • 5
  • 15
0

Thanks for following up with you solution Oggie. I just ran into the same symptom and have overcome with your new user fix.

Further info: I was able to get the old username and password to work by deleting the old user and creating a new user with exactly the same username and password. (Though I experimented with a new user with same/different passwords along the way).

With regard to the cause... I have little idea. We run Archiva on the same machine as UberSVN, and our Jenkins sits inside UberSVN as a plugin. No upgrades were made to any of these. There were however a number of ownership changes made to various directories on the server, though I can't see those being the cause given the solution was to simply create a new user.

Thanks again for the post.

JonoWilko
  • 31
  • 1
0

I missed giving the deployment user the Role RepositoryManager after re-creating my Archiva repository. After adding the role, it solved the 401 when uploading artifacts.

See Archiva User Guide.

ulrich
  • 1,431
  • 3
  • 17
  • 46
0

I had same problem and based on the Jenkins issues reported to Helpdesk it is also possible that there is some problem with your account (infrastructure problem).

Verify https://www.jenkins.io/doc/developer/publishing/releasing-manually/ and if you find something weird with your Jenkins account try https://github.com/jenkins-infra/helpdesk

Damian
  • 437
  • 5
  • 11