It seems like another bug in Jenkins. Using freestyle the build cause for the downstream project is upstream, while for multi-config the build cause is the same as for the upstream project.
I created a new Jenkins issue for this: https://issues.jenkins-ci.org/browse/JENKINS-27353 onsdag 11. mars 2015 10.06.31 UTC+1 skrev Sverre Moe følgende: > > Seems Jenkins issue #24785 was fixed by introducing ROOT_BUILD_CAUSE. It > is a little bit helpful, but does not help with the downstream triggered > projects. > ProjectA is triggered and ROOT_BUILD_CAUSE == MANUALTRIGGER > ProjectB is triggered from ProjectA and ROOT_BULD_CAUSE == MANUALTRIGGER. > > ProjectB was never triggered manually, but as a downstream trigger from > ProjectA. > So I need to find out if a Project is triggered by User, SCM or if it was > triggered from an upstream project. > > Wonder if this is yet another bug in Jenkins. Downstream project should > not get the same (ROOT_)BUILD_CAUSE as its upstream project. > > onsdag 11. mars 2015 09.12.44 UTC+1 skrev Björn Pedersen følgende: >> >> Hi, >> >> maybe it is issue #24785 >> <http://issues.jenkins-ci.org/browse/JENKINS-24785> what is causing this >> behaviuor? >> >> Björn >> >> Am Mittwoch, 11. März 2015 08:55:45 UTC+1 schrieb Sverre Moe: >>> >>> Running a script in Groovy Postbuild. >>> >>> All my projects are *Multi-configuration project*, Matrix build. When I >>> trigger the build manually, the cause is UpstreamCause, but toString() >>> contains UserIdCause. When one of my projects gets triggered from a >>> upstream project, then the cause is still UpstreamCause, with content >>> UserIdCause. >>> I have a script I want to run only if it is UpstreamCause, i.e. >>> triggered by an upstream project. >>> >>> ProjectA: >>> manager.build.getCauses().each { cause -> >>> cause.toString() == >>> "job/projectA/148[job/projectA/14[hudson.model.Cause$UserIdCause@caebc9aa]]" >>> cause.getClass() == "class hudson.model.Cause$UpstreamCause" >>> } >>> >>> >>> ProjectB triggered by ProjectA: >>> manager.build.getCauses().each { cause -> >>> cause.toString() == >>> "job/projectB/14[hudson.model.Cause$UserIdCause@caebc9aa]" >>> cause.getClass() == "class hudson.model.Cause$UpstreamCause" >>> } >>> >>> >>> I need to check if a project has been triggered because of an upstream >>> project, but if everything is upstream then what is the point of the Cause. >>> Last resort: parse cause..getShortDescription() >>> Started by upstream project "projectA" build number 148 >>> if (cause.getShortDescription().contains("Started by upstream project") >>> >>> >>> Tried accessing through variable, >>> def userCause = manager.envVars["BUILD_CAUSE"] >>> but in both these cases the cause is UPSTREAMTRIGGER. It seems like the >>> downstream project inherits the cause from the upstream project. >>> >>> >>> mandag 23. februar 2015 17.11.16 UTC+1 skrev Baptiste Mathus følgende: >>>> >>>> Basically groovy script are just like java code with syntactical sugar. >>>> I mean if you find the Jenkins api you want to use, doing it in groovy is >>>> generally very very easy. >>>> In your case the "hardest" part is getting hold onto the current build >>>> reference in a system groovy script in a build step. Then the rest is east >>>> as you already found where to begin (if not have a look at the build >>>> trigger badge plugin code [shameless plug]). >>>> >>>> And if this if something you want to offer as a simple build feature, >>>> then writing a plugin might even be a good and quite simple way too. >>>> >>>> Cheers >>>> Le 23 févr. 2015 14:17, "Sverre Moe" <[email protected]> a écrit : >>>> >>>>> It seems also like there is access to the build cause in the Jenkins >>>>> API. >>>>> http://javadoc.jenkins-ci.org/hudson/model/Cause.html >>>>> >>>>> So instead of accessing an environment variable, I could instead >>>>> access it programmatically in my Groovy build script. >>>>> Trying to find any groovy script examples using Cause from Jenkins >>>>> API, no such luck. >>>>> >>>>> torsdag 19. februar 2015 14.39.54 UTC+1 skrev rginga følgende: >>>>>> >>>>>> Basically, many plugins contribute tokens. I think these come from >>>>>> the Environment inject plugin: >>>>>> >>>>>> >>>>>> >>>>>> *Build Causes* >>>>>> >>>>>> This plugin also exposes the cause of the current build as an >>>>>> environment variable. A build can be triggered by multiple causes at the >>>>>> same time e.g. an SCM Change could have occurred at the same time as a >>>>>> user >>>>>> triggers the build manually. >>>>>> >>>>>> The build cause is exposed as a coma separated list: >>>>>> >>>>>> BUILD_CAUSE=USERIDCAUSE, SCMTRIGGER, UPSTREAMTRIGGER >>>>>> >>>>>> In addition, each cause is exposed as a single envvariable too: >>>>>> >>>>>> BUILD_CAUSE_USERIDCAUSE=true >>>>>> >>>>>> BUILD_CAUSE_SCMTRIGGER=true >>>>>> >>>>>> BUILD_CAUSE_UPSTREAMTRIGGER=true >>>>>> >>>>>> >>>>>> >>>>>> It looks like you can get the user id >>>>>> >>>>>> >>>>>> >>>>>> *From:* [email protected] [mailto:jenkins...@ >>>>>> googlegroups.com] *On Behalf Of *Sverre Moe >>>>>> *Sent:* Thursday, February 19, 2015 6:54 AM >>>>>> *To:* [email protected] >>>>>> *Subject:* Re: Groovy build script: What triggered the build >>>>>> >>>>>> >>>>>> >>>>>> Excellent. I could not find any documentation about this variable. It >>>>>> is not listed among the environment variables of Jenkins. Makes me >>>>>> wonder >>>>>> which other variables are available that could be usefull. >>>>>> >>>>>> >>>>>> >>>>>> When I trigger the build manually in Jenkins I got BUILD_CASE = >>>>>> UPSTREAMTRIGGER >>>>>> >>>>>> When triggered by SCM change BUILD_CAUSE = SCMTRIGGER. >>>>>> >>>>>> When triggered by an downstream project UPSTREAMTRIGGER (a library >>>>>> triggered a build on the app that uses it. >>>>>> >>>>>> >>>>>> >>>>>> So it looks like the BUILD_CAUSE is the same for both manually >>>>>> trigger and triggered by an upstream/downstream project. >>>>>> >>>>>> However I think I could work this that since I would have the same >>>>>> build procedure for both manual and automatic UPSTREAMTRIGGER build. >>>>>> >>>>>> Still would be nice to also have BUILD_CAUSE_BY, user or project. >>>>>> >>>>>> >>>>>> >>>>>> Where do I find a complete list of variables I could use? >>>>>> >>>>>> >>>>>> tirsdag 17. februar 2015 14.21.59 UTC+1 skrev rginga følgende: >>>>>> >>>>>> There is a BUILD_CAUSE environment variable that can have values >>>>>> like: SCMTRIGGER, MANUALTRIGGER, and others >>>>>> >>>>>> >>>>>> >>>>>> *From:* [email protected] [mailto:jenkins...@ >>>>>> googlegroups.com] *On Behalf Of *Sverre Moe >>>>>> *Sent:* Monday, February 16, 2015 7:06 AM >>>>>> *To:* [email protected] >>>>>> *Subject:* Groovy build script: What triggered the build >>>>>> >>>>>> >>>>>> >>>>>> Is it possible to find out who or what triggered the build from a >>>>>> Groovy script? Either an SCM change, another project or user. I have >>>>>> just >>>>>> begun reading a little about Groovy and the Jenkins API. >>>>>> >>>>>> >>>>>> >>>>>> I want to check for the following conditions and build accordingly. >>>>>> >>>>>> >>>>>> >>>>>> if (trigger == scm) { >>>>>> >>>>>> build_with_automake >>>>>> >>>>>> new_version = git tag exist for version >>>>>> >>>>>> if (new_version) { >>>>>> >>>>>> tag new release candidate in Git >>>>>> >>>>>> publish rc >>>>>> >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> else if (trigger == "Build other projects") { >>>>>> >>>>>> build_with_automake >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> The project should build on every SCM change, but only tag and >>>>>> publish if version has been increased. It should also build when a build >>>>>> has been triggered by another project. >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/jenkinsci-users/a4a10f09-9846-4c6e-b572- >>>>>> ed5123f0977d%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/a4a10f09-9846-4c6e-b572-ed5123f0977d%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/jenkinsci-users/ef08a7f4-380f-40da-bcc3- >>>>>> 649188688ee1%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/ef08a7f4-380f-40da-bcc3-649188688ee1%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jenkinsci-users/f08241c9-98cd-46e9-9c4d-47e80ee84a30%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/jenkinsci-users/f08241c9-98cd-46e9-9c4d-47e80ee84a30%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c690b72e-166b-4452-b4ff-537f5dbb00e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
