Subversion post-commit hook succeeds but doesn't trigger build

5 messages

Subversion post-commit hook succeeds but doesn't trigger build

Reply Threaded

I resolved this problem. Details below.

I started off adjusted the logging levels so I got a message "Change reported to Subversion repository" with the name of the affected file for the given revision. This was not followed by "Scheduling the immediate polling of..." message, which is logged at the same level. According to the source code of the SubversionRepositoryStatus class, this could only happen if:

The project is not in the list of projects returned by Hudson.getInstance().getItems(AbstractProject.class). (line 65)

Can't verify, but how could this be true?

The project does not use Subversion as its SCM. (line 68)

No, SCM is set to "Subversion."

The project does not have an SCMTrigger. (line 71)

No, the build trigger is "Poll SCM."

The ModuleLocation's UUID does not match the UUID defined in the wget request. (line 75)

According to svn info on Hudson's working copy, they match.

The SVN URL does not contain the repository root path. (line 79)

According to svn info on Hudson's working copy, it does.

No paths were affected. (line 85)

They were.

One thing I did notice is that there are a number of permission checks, all of which return false. I figured this must be part of item 1, iterating through all the jobs. Interestingly, despite providing credentials to wget, my username was "anonymous" in the logs. This led me to believe that this was related to a problem I encountered earlier and something which others have seen as well.

The solution was to add --auth-no-challenge to the wget command in the post-commit hook. This is because Hudson "does not do any authorization negotiation . Ie. it immediately returns a 403 (Forbidden) response instead of a 401 (Unauthorized) response."

Mark Russell-3

Re: Subversion post-commit hook succeeds but doesn't trigger build

Reply Threaded

We are having similar issues. Could you let me know what values you changed to get the log output?

Mark Lewis wrote:

> I resolved this problem. Details below.
>
> I started off adjusted the logging levels so I got a message "Change
> reported to Subversion repository" with the name of the affected file
> for the given revision. This was not followed by "Scheduling the
> immediate polling of..." message, which is logged at the same level.
> According to the source code of the SubversionRepositoryStatus class,
> this could only happen if:
>
> 1. The project is not in the list of projects returned by
> Hudson.getInstance().getItems(AbstractProject.class). (line 65)
> * Can't verify, but how could this be true?
> 2. The project does not use Subversion as its SCM. (line 68)
> * No, SCM is set to "Subversion."
> 3. The project does not have an SCMTrigger. (line 71)
> * No, the build trigger is "Poll SCM."
> 4. The ModuleLocation's UUID does not match the UUID defined in the
> wget request. (line 75)
> * According to svn info on Hudson's working copy, they match.
> 5. The SVN URL does not contain the repository root path. (line 79)
> * According to svn info on Hudson's working copy, it does.
> 6. No paths were affected. (line 85)
> * They were.
>
> One thing I did notice is that there are a number of permission checks,
> all of which return false. I figured this must be part of item 1,
> iterating through all the jobs. Interestingly, despite providing
> credentials to wget, my username was "anonymous" in the logs. This led
> me to believe that this was related to a problem I encountered
> <http://www.nabble.com/Hudson-returns-HTTP-403-to-Subversion-post-commit-hook-td26034196.html>
> earlier
> <http://www.nabble.com/Hudson-returns-HTTP-403-to-Subversion-post-commit-hook-td26098445.html>
> and something which others
> <http://www.nabble.com/Authentication-and-trigger-builds-remotely-td15053538.html#a22096093>
> have seen as well.
>
> The solution
> <http://wiki.hudson-ci.org/display/HUDSON/Authenticating+scripted+clients>
> was to add --auth-no-challenge to the wget command in the post-commit
> hook. This is because Hudson "does not do any authorization negotiation
> . Ie. it immediately returns a 403 (Forbidden) response instead of a 401
> (Unauthorized) response."

--
Mark Russell
Build Master
Instantiations, Inc.
+1 724-368-3331 (land line)
http://www.instantiations.com

smime.p7s (4K) Download Attachment

Villemos, Gert

Failure to deploy artefact to artifactory - code 401

Reply Threaded

We are building a Maven2 multi-module project using Hudson v1.323. When
using the 'deploy' goal, the build fails with the exception;

[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error deploying artifact: Failed to transfer file:
http://10.48.29.168:8888/artifactory-2.0.5/internal-repository/esa/dops/
game/game/1/game-1.pom. Return code is: 401
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifact: Failed to transfer file:
http://10.48.29.168:8888/artifactory-2.0.5/internal-repository/esa/dops/
game/game/1/game-1.pom. Return code is: 401
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default
LifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec
ycle(DefaultLifecycleExecutor.java:540)
...

It seems Hudson / maven2 are not authorized to deploy artefacts to the
repository. We have updated the local Hudson .m2/settings.xml file to
contain;

<servers>
<server>
<id>internal-repository</id>
<username>[username]</username>
<password>[password]</password>
</server>
</servers>

<repositories>
<repository>
<id>internal-repository</id>

<url>http://[IP]/artifactory-2.0.5/internal-repository/</url>
</repository>
</repositories>

URL and user / password are correct. What are we doing wrong?

Thanks,
Gert.

Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu schützen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Villemos, Gert

RE: Failure to deploy artefact to artifactory - code 401

Reply Threaded

After disabling the password encryption in Artifactory (Admin->Security->General) it works.

-----Original Message-----
From: Villemos, Gert [mailto:[hidden email]]
Sent: Wednesday, November 04, 2009 2:27 PM
To: [hidden email]
Subject: Failure to deploy artefact to artifactory - code 401

We are building a Maven2 multi-module project using Hudson v1.323. When using the 'deploy' goal, the build fails with the exception;

[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error deploying artifact: Failed to transfer file:
http://10.48.29.168:8888/artifactory-2.0.5/internal-repository/esa/dops/
game/game/1/game-1.pom. Return code is: 401 [INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifact: Failed to transfer file:
http://10.48.29.168:8888/artifactory-2.0.5/internal-repository/esa/dops/
game/game/1/game-1.pom. Return code is: 401
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default
LifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec
ycle(DefaultLifecycleExecutor.java:540)
...

It seems Hudson / maven2 are not authorized to deploy artefacts to the repository. We have updated the local Hudson .m2/settings.xml file to contain;

<servers>
<server>
<id>internal-repository</id>
<username>[username]</username>
<password>[password]</password>
</server>
</servers>

<repositories>
<repository>
<id>internal-repository</id>

<url>http://[IP]/artifactory-2.0.5/internal-repository/</url>
</repository>
</repositories>

URL and user / password are correct. What are we doing wrong?

Thanks,
Gert.

Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu schützen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu schützen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

taciano.tres

Re: Failure to deploy artefact to artifactory - code 401

Reply Threaded

In reply to this post by Villemos, Gert

Gert, have you checked the Artifactory log's? When I'd have this problem Artifactory's log show the problem: authenticated user missed access in the repository for upload.

Note also that, if you are uploading an artifact that already exists in the repository (game-1.pom has already been deployed?) then the user authenticated by Hudson should have 'delete' rights to replace it.

Another tip is to check the Maven version you're using: since 2.1.0 there's a new feature called Password encryption (http://maven.apache.org/guides/mini/guide-encryption.html), so the Artifactory's user password should be 'escaped'.
---
Taciano Tres
[hidden email]

"Villemos, Gert" <[hidden email]>

05/11/2009 10:03 CET
Favor responder a users

Para: <[hidden email]>
cc: (cco: F9256998 Taciano Tres/BANCO DO BRASIL)
Assunto: RE: Failure to deploy artefact to artifactory - code 401