Job properties are not (should be !?) cumulative

[ncosta-2]

Project properties are not cumulative when additional settings are set during the pipeline.

For example, if setting a Parameterized build and later in the pipeline, a Discard Old Builds is set, the Parameterized build is unset.

I had this happening when the Discard Old Builds were used in a Shared library, later in the pipeline.

When a additional propertie is set, it shouldn't unset all the previous properties, if they are not the same type (discard builds vs parameters).

Someone know if this is working as designed or is something that could be implemented?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/f4ad1274-d5ad-470c-9c8a-6e8f7a3483b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Stave]

It also means if you use a JobDSL statement to generate a Pipeline job with 

  authorization {
     permission('...

then if your Pipeline Jenkinsfile uses

options {
    buildDiscarder(

It wipes out the permissions, since they both use the properties mechanism, which only works once. 

I'm not sure if that's a bug or missing feature, but it's annoying

On Friday, May 19, 2017 at 3:28:12 AM UTC-5, [hidden email] wrote:

Project properties are not cumulative when additional settings are set during the pipeline.

For example, if setting a Parameterized build and later in the pipeline, a Discard Old Builds is set, the Parameterized build is unset.

I had this happening when the Discard Old Builds were used in a Shared library, later in the pipeline.

When a additional propertie is set, it shouldn't unset all the previous properties, if they are not the same type (discard builds vs parameters).

Someone know if this is working as designed or is something that could be implemented?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ee101289-52ff-4c27-a11c-eb9c962fe8d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[harold.putman]

Yes it is working as designed. 

https://jenkins.io/doc/pipeline/steps/workflow-multibranch/#properties-set-job-properties

"Note that any existing properties of the job will be replaced with the list given here."

It would be nice to be able to modify job properties rather than overwrite everything. It makes for a confusing user experience when you set job properties manually, and then have them blown away when your pipeline job runs. 

I've been working around it by first reading the properties I want to preserve and then writing them back, but this is ugly and very undocumented.

On Friday, May 19, 2017 at 4:28:12 AM UTC-4, [hidden email] wrote:

Project properties are not cumulative when additional settings are set during the pipeline.

For example, if setting a Parameterized build and later in the pipeline, a Discard Old Builds is set, the Parameterized build is unset.

I had this happening when the Discard Old Builds were used in a Shared library, later in the pipeline.

When a additional propertie is set, it shouldn't unset all the previous properties, if they are not the same type (discard builds vs parameters).

Someone know if this is working as designed or is something that could be implemented?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/167f7cb9-64fd-4f85-b473-0cde1f7613e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.