5

My Jenkins is affected by a known Jenkins bug where it will trigger jobs that have an SCM poll set if a change to the shared library happens. I can't have this, so I thought I would get the trigger info from inside the job and if the URL was from the library repo I would abort the build. This has proven to be extremely difficult to do.

This doesn't work...

println ("Cause: " + currentBuild.causes[0])

or

print currentBuild.rawBuild.getCause(hudson.triggers.SCMTrigger$SCMTriggerCause)

or

def causes = currentBuild.rawBuild.getCauses()
for (cause in causes) {
    print cause
}

The first example barfs

org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: unclassified field org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper causes
    at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.unclassifiedField(SandboxInterceptor.java:397)
    at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:381)

but doesn't allow me to whitelist it on the script security page.

The last 2 print thing hudson.triggers.SCMTrigger$SCMTriggerCause@3 but it seems the only thing I can do is call getShortDescription() and it prints Started by an SCM change.

If you know how to print more information about an SCM trigger such as the URL please share =).

Community
  • 1
Levi
  • 1,044
  • 6
  • 18

3 Answers3

1

Recently, I used this code snippet (that's part of a regular groovy script located inside the 'vars/' directory) to get the project URL as set in the pipeline project config. Hope this helps.

scm.getUserRemoteConfigs()[0].getUrl()

FYI, it does not expect to have any SCM operation to have taken place.

For more info, refer to this SO thread.

Hopefully, am not violating the devops stackexchange ground rules with this reference to stack overflow.

Ramu
  • 31
  • 1
  • No worries, making references to SO posts is fine. – Dan Cornilescu May 24 '18 at 04:26
  • After all these years I came back to upvote this. I have been parsing the URL from sh step using git remote this entire time =/. The global variable docs says scm is only avaliable in a multibranch pipeline but I'm guess it will work anytime you have configured your giturl and branch in the job config page but I need to test this. – Levi Jun 13 '21 at 07:51
1

Some bad news and some good news :)

Bad news:

not a bug. this is a feature (default behaviour)

I don't understand why this bug is still open, either regression, or miscommunication.

Good news:

During setup of Global Shared Libraries jenkins allows to mark whether you should trigger user jobs upon changes in the library. And, you can also mark this during library usage in the job's groovy.

Please refer to:

mvk_il
  • 166
  • 3
0

Unfortunately I had to disable the Groovy sandbox because I ran into so many situations where methods I wanted to use in my jobs did not appear available for whitelist on the script security page. Instead of adding a bunch of individual method calls to a whitelist or disabling the sandbox, you can also use a global shared library, since global shared libraries are automatically whitelisted in the sandbox. (The shared library approach worked well for me at first, but eventually I ran into situations where I did not feel that the code I was writing was appropriate for a shared library, so I just disabled the sandbox as it had never provided any benefit to me anyway. Just as a warning, disabling the sandbox is usually fine in single-tenancy situations, but not in multi-tenancy Jenkins instances.)

As for your code, unfortunately SCMTriggerCause doesn't appear to have any properties pointing to the actual URL of the SCM source (I can't confirm this as I don't use SCM polling on my Jenkins instance). Instead you could try something like this:

currentBuild.rawBuild.changeSets.collect { it.browser.repoUrl }
jayhendren
  • 2,952
  • 7
  • 15
  • I looked at changesets when the job was running using the API, did not see url. I will relook.

    EDIT: I'm not seeing it in the rest API but I will try it anyways. When I get a chance.

     – Levi Apr 04 '18 at 18:22
  • That's because the URL isn't attached to the changeset directly - it's attached to a browser object, which you will have if you are using GitHub or Bitbucket plugins. – jayhendren Apr 04 '18 at 21:50
  • All that printed was an empty list. I think it's a good answer, but not for my situation. Something I'm def going to save in my toolbox. – Levi Apr 04 '18 at 22:53