SVN post commit hook - no subversion consumers for UUID

[James Telfer]

Hi all,

I've been working through this issue and trying to read other resources on post-commit hooks without finding a match for the issue I'm experiencing.

My jobs work fine, and SVN polling is working and triggering builds. However, the post-commit hook in SVN doesn't trigger a build. Instead, the following is written to the log:

Nov 10, 2014 11:50:33 AM jenkins.scm.impl.subversion.SubversionSCMSource$ListenerImpl onNotify
INFO: Received post-commit hook from 104ea3cd-1caa-42bb-bcc1-xxxxxxxxxxxx for revision 120,169 on paths [src/trunk/mgs/, ... (correct comma-separated path list)]
Nov 10, 2014 11:50:33 AM jenkins.scm.impl.subversion.SubversionSCMSource$ListenerImpl onNotify
INFO: No subversion consumers for UUID 104ea3cd-1caa-42bb-bcc1-xxxxxxxxxxxx

So far:

• The job is working manually, and via SVN polling
• The SCM trigger does not deny post-commit hooks
• The UUID is correct
• The paths appear to be correct
• The post-commit hook is using basic auth with a valid user name and API key (these work -- I used to trigger specific builds using this script)
• I'm not using the BlameSubversion plugin
• I have Jenkins 1.570 and SVN plugin 2.3.
• The SVN checkout for this item is marked with depth 'empty', but the source code appears only to check against the UUID (at this level).
  

I looked at the code for SubversionSCMSource.onNotify and setup a logger at level 'FINE' for that class. Nothing interesting. I tried:

for (SCMSourceOwner owner : SCMSourceOwners.all()) { 

    println owner 

}

In the console and found the collection has no elements. I tried:

println Jenkins.instance.getAllItems(SCMSource.class)

as well but that's empty too.

At this point I'm at a loss. It might need to be anonymous instead of using basic auth (I'm trying that out) but apart from that I'm out of ideas.

Does anyone have any other ideas I can try?

Thanks in advance,

James

[Brantley Hobbs]

James,

We are also experiencing this same issue.  Were you able to find more information?

Thanks,

Brantley

[Mark Lewis]

I am Brantley's colleague. Just in case this was tied to security, I converted this block of code to the following Groovy script which should print them all:

import hudson.security.ACL

import jenkins.scm.api.SCMSource

import jenkins.scm.api.SCMSourceOwners

import org.acegisecurity.context.SecurityContextHolder

import org.acegisecurity.Authentication

Authentication old = SecurityContextHolder.getContext().getAuthentication()

SecurityContextHolder.getContext().setAuthentication(ACL.SYSTEM)

try {

  for(SCMSource e in SCMSourceOwners.all()) {

    println(e)

  }

} finally {

  SecurityContextHolder.getContext().setAuthentication(old)

}

Instead, it prints nothing.

On Tuesday, November 11, 2014 at 4:20:52 AM UTC-5, James Telfer wrote:

[Mark Lewis]

I'm able to get a list of projects putting this in the console:

println Jenkins.instance.getAllItems()

However, none of the types shown extend SCMSourceOwner (e.g. hudson.model.FreeStyleProject).

The implementation of getAllItems() is checking types, and since the new scm-api is looking for Items that extend SCMSourceOwner, the type check fails and the project is excluded from the results. Still digging.

[Daniel Beck]

Are you sure you're not being misled by that log message?

The real trigger happens at
https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionRepositoryStatus.java#L165

It also uses the logger of SubversionRepositoryStatus to inform about its actions -- watch what it's doing there.

The log message refers to further extensions hooking into this mechanism via SCM API plugin and has nothing to do with basic triggering of builds.

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e39dd500-2954-416a-aa55-e1d07ded09c3%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mark Lewis]

Daniel, I wish that were the case, but I set logging to ALL and none of the messages from SubversionRepositoryStatus were logged. The OP set logging to FINE. I expect one of us would've seen messages for the process starting and ending. This suggests to me that SubversionRepositoryStatus.JobTriggerListenerImpl.onNotify() is not being invoked.

I'm using Jenkins 1.599 and Subversion 2.5.

[Daniel Beck]

On 25.02.2015, at 00:39, Mark Lewis <malfun...@gmail.com> wrote:

> The OP set logging to FINE.

For the wrong logger. Quoting:

> I looked at the code for SubversionSCMSource.onNotify and setup a logger at level 'FINE' for that class. Nothing interesting.

Make sure to create a log recorder for the logger hudson.scm.SubversionRepositoryStatus only, on level FINE or higher. What does it report the next time you send the post-commit hook?

[Mark Lewis]

Daniel,

I had set logging to ALL globally, and it didn't print anything for SubversionRepositoryStatus when I triggered the post-commit. Weird.

Following your instructions, I can see it is getting triggered. Thanks for helping me rule that out.

[Mark Lewis]

So our problem was with the post-commit hook. We've got our hooks running a PHP script so we can easily manage them in a DB, and we had recently switched from using exec calls of wget to PHP's curl. We thought this had been working but it had not.

For anyone reading at home, PHP's curl doing POSTs will silently ignore your requests to change the Content-Type header to text/plain;charset=UTF-8.  Instead, it will choose the Content-Type header for you based on what kind of data you provide to POSTFIELDS, and it appears you cannot override it.