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.
I think that the point here should not to control job's
overridingoverwriting 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.