Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-39765

freeStyleJob should support an update argument to specify if you want or not override

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • job-dsl-plugin
    • None

      Create the following JobDSL job.

      freeStyleJob("tryDSL") { 
description("This a new job") 
steps { 
shell('echo "Hello World "') 
} 
}

      If there is a job which already has this name `tryDSL` on the instance, it will overwrite itself with the awaited content brought by the DSL script.

      freeStyleJob should support an update boolean argument to specify if you want or not override

        1. screenshot-1.png
          screenshot-1.png
          9 kB

          [JENKINS-39765] freeStyleJob should support an update argument to specify if you want or not override

          Félix Belzunce Arcos created issue -

          jlpinardon added a comment -

          I think that the point here should not to control job's overriding overwriting in every cases, but only if one of the jobs (re)generated within a DSL script has the same name as the seed job.
          In other words,it should only control the case where the "tryDSL" seed job's DSL scripts tries to create a job named "tryDSL" in the same folder than the seed job. It is actually a security option, which should be activated by default and lead to a seed job failure if the case is encountered.

          jlpinardon added a comment - I think that the point here should not to control job's overriding overwriting in every cases, but only if one of the jobs (re)generated within a DSL script has the same name as the seed job. In other words,it should only control the case where the " tryDSL " seed job's DSL scripts tries to create a job named " tryDSL " in the same folder than the seed job. It is actually a security option, which should be activated by default and lead to a seed job failure if the case is encountered.

          Daniel Spilker added a comment -

          The "Process Job DSLs" build step has an option "Action for existing jobs and views". If you select "Ignore changes", no job or view is updated. Isn't that sufficient?

          Daniel Spilker added a comment - The "Process Job DSLs" build step has an option "Action for existing jobs and views". If you select "Ignore changes", no job or view is updated. Isn't that sufficient?
          jlpinardon made changes -
          Attachment New: screenshot-1.png [ 35829 ]

          jlpinardon added a comment -

          Well, at least it avoids the DSL seed job to be overwritten. It is a good point.
          But :

          1. In this specific case, it should be the default behavior
          2. The job is still SUCCESS, though it has not done at all what it is supposed to do.
          3. The console log does not help to quickly understand goes wrong.
          4. And worst, the job page shows something which is clearly wrong :

            It looks like something has been generated though it is absolutely (and fortunately) not the case.

          So, this option is less than sufficient. I would say that it is not suitable for such a control.

          Unless you know use cases where it is useful that a seed job generates a job that overwrite its seed job (something like a burn after reading use case ?), IMHO the default behavior for a seed job should be to fail if the seed job generated something that overwrites itself. I understand that in a real world, the DSL job will create several jobs among which the seed can be hidden... To discover it before the generation (and fails it) could be less than obvious. And so, if it is discovered on the fly, the job will fail, but should the whole generation be thrown up, or the other generated jobs be preserved... not sure of the good choice.

          jlpinardon added a comment - Well, at least it avoids the DSL seed job to be overwritten. It is a good point. But : In this specific case, it should be the default behavior The job is still SUCCESS, though it has not done at all what it is supposed to do. The console log does not help to quickly understand goes wrong. And worst, the job page shows something which is clearly wrong : It looks like something has been generated though it is absolutely (and fortunately) not the case. So, this option is less than sufficient. I would say that it is not suitable for such a control. Unless you know use cases where it is useful that a seed job generates a job that overwrite its seed job (something like a burn after reading use case ?), IMHO the default behavior for a seed job should be to fail if the seed job generated something that overwrites itself. I understand that in a real world, the DSL job will create several jobs among which the seed can be hidden... To discover it before the generation (and fails it) could be less than obvious. And so, if it is discovered on the fly, the job will fail, but should the whole generation be thrown up, or the other generated jobs be preserved... not sure of the good choice.
          Jamie Tanna made changes -
          Assignee Original: Daniel Spilker [ daspilker ] New: Jamie Tanna [ jamietanna ]

            jamietanna Jamie Tanna
            fbelzunc Félix Belzunce Arcos
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: