I am using Pipeline Global Library along with Jenkinsfile. All build logic
is in a centralized build script within Jenkins workflowLibs.git
Setting properties to be used on branches:
properties([[$class: 'ParametersDefinitionProperty', parameterDefinitions:
[[$class: 'BooleanParameterDefinition', defaultValue: false, description:
'Parameter
Text', name: 'MY_PARAM']]]])
The properties set during execution of a build will be available next time
a build is started.
I used the following piece of code to check for this property in my build
script
def myBoolParam = false
if (getBinding().hasVariable("MY_PARAM")) {
myBoolParam = Boolean.parseBoolean(MY_PARAM)
}
torsdag 4. august 2016 06.25.13 UTC+2 skrev Advait Chabukswar følgende:
>
> Sverre, can you elabore a bit more on how you did this?
>
> So, I am automating the creation and working of Multibranch Pipeline. I am
> able to create jobs through Job DSL and it works fine.
> But I have some variables(or parameters) that I want to pass to the
> individual branches (and I want it to be automated on job creation). If I
> put it in the Jenkinsfile, it won't be scalable.
>
> I do it for regular pipeline jobs by using the EnvInject plugin, can't use
> that here though.
> Do you have any solutions for this?
>
> On Wednesday, June 22, 2016 at 2:49:32 AM UTC-5, Sverre Moe wrote:
>>
>> It seems there is no point with Envinject-plugin with Pipeline
>> There is an issue for removing it in the configuration screen.
>> https://issues.jenkins-ci.org/browse/JENKINS-26569
>>
>> Then this is no longer an issue for me. Using the properties context in
>> the script I was able to add parameters to my multibranch pipeline.
>>
>> onsdag 22. juni 2016 08.45.18 UTC+2 skrev Sverre Moe følgende:
>>>
>>> Found some clue in https://issues.jenkins-ci.org/browse/JENKINS-32780
>>> Using the Snippet code generator I was able to generate a build parameter
>>> properties [[$class: 'ParametersDefinitionProperty',
>>> parameterDefinitions: [[$class: 'BooleanParameterDefinition', defaultValue:
>>> false, description: 'Force publish RPM artifacts to repository', name:
>>> 'FORCE_PUBLISH']]]]
>>>
>>> If I want all branches to have this property, could I put it in my
>>> global script? I am trying to keep my Jenkinsfiles as DRY as possible.
>>>
>>> Using the Snippet generator to "Prepare an environment for the run"
>>> This is needed because of SECURITY-170, otherwised properties are not
>>> propagated to downstream builds.
>>> It does not generate anything useful. Previously the result was empty
>>> whatever I put within "Properties Content". Now I only get
>>> properties [<object of type org.jenkinsci.plugins.envinject.
>>> EnvInjectJobProperty>]
>>> This is what the snippet generator gives me for any of the choices,
>>> script, file or content.
>>>
>>>
>>>
>>> onsdag 22. juni 2016 08.27.13 UTC+2 skrev Sverre Moe følgende:
>>>>
>>>> Each branch pipeline has their own config.xml. A standard pipeline job
>>>> does have support for parameterization. I think I read somewhere in
>>>> Jenkins
>>>> JIRA that such properties should be defined in the Jenkinsfile and set for
>>>> the branch pipeline project on the first run. I am a bit unsure how to set
>>>> them. Cannot find a single example of this.
>>>>
>>>> https://issues.jenkins-ci.org/browse/JENKINS-30519
>>>>
>>>> I know how to set them programatically in the Script console for
>>>> "regular" projects.
>>>> StringBuilder builder = new StringBuilder()
>>>> builder.append("PROP1=true")
>>>> builder.append("\n")
>>>> builder.append("PROP2=true")
>>>> final def propertiesContent = builder.toString()
>>>>
>>>> def info = new EnvInjectJobPropertyInfo(null, propertiesContent,
>>>> null, null, null, false)
>>>> def property = new EnvInjectJobProperty()
>>>> property.setOn(true)
>>>> property.setKeepJenkinsSystemVariables(true)
>>>> property.setKeepBuildVariables(true)
>>>> property.setInfo(info)
>>>>
>>>> project.addProperty(property)
>>>> project.save()
>>>>
>>>>
>>>> mandag 13. juni 2016 10.20.55 UTC+2 skrev Sverre Moe følgende:
>>>>>
>>>>> Either I am doing it wrong, or Multibranch pipeline has no way of
>>>>> sending parameters to downstream builds.
>>>>> Considering that each branch within a multibranch pipeline seems to be
>>>>> a single Pipeline project and standard such Pipeline projects can be
>>>>> parameterized.
>>>>>
>>>>> onsdag 8. juni 2016 12.42.01 UTC+2 skrev Sverre Moe følgende:
>>>>>>
>>>>>> Jenkins Pipeline can be parameterized, but not multibranch pipelines.
>>>>>> There is no option for "This build is parameterized" in the
>>>>>> configuration
>>>>>> of a multibranch pipeline. Why is that?
>>>>>>
>>>>>> I have a multibranch project for each repository with multiple
>>>>>> branches.
>>>>>>
>>>>>> ProjectA
>>>>>> master
>>>>>> develop
>>>>>> releaseX
>>>>>> ProjectB
>>>>>> master
>>>>>> develop
>>>>>> releaseX
>>>>>>
>>>>>> In this case ProjectB has a dependency on ProjectA on the same branch.
>>>>>>
>>>>>> The Jenkinsfile is sparse, while the common main build logic is
>>>>>> stored in workflowLibs.git
>>>>>>
>>>>>> When a upstream project builds a dependent downstream project I need
>>>>>> to provide them with build parameters.
>>>>>> def BUILD_PROJECT = "projectB"+"/"+env.BUILD_BRANCH
>>>>>> build job: BUILD_PROJECT, parameters: [[$class:
>>>>>> 'BooleanParameterValue', name: 'UPSTREAM_TRIGGERED', value: true]]
>>>>>> I have some logic in the main build script for when the build is
>>>>>> triggered by an upstream dependency.
>>>>>>
>>>>>> Not sure how I can do this since multibranch pipeline cannot be
>>>>>> parameterized.
>>>>>>
>>>>>> I have even tried withEnv, but it did not work
>>>>>> withEnv(["UPSTREAM_TRIGGERED=true"]) {
>>>>>> def BUILD_PROJECT = "projectB"+"/"+env.BUILD_BRANCH
>>>>>> build BUILD_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/838de283-98e7-4d5e-a4de-91c16b8e1c5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
