Hi,

      Would it be possible to have an extension point, through a dedicated ExtensibleContext, which allows to add some code at the root of a DSL, at the same level than job and co?

      The use case is as follows: among activities we want to achieve when generating the jobs of a pipeline, we want to perform other tasks, like creating branches in Ontrack or initialising some repositories in Artifactory.

      The current way we do it is to generate a setup job which is queued automatically at the end of the pipeline generation, but that's a bit heavy.

      It would be neat if we could call some plugin's code, through an extension or directly.

          [JENKINS-31912] Extension point at the root of the DSL?

          damien_coraboeuf do you still need this? Do you need this for the seed plugin? I assume that you are using DslScriptLoader directly instead of the build step. With PR #984 I'm going to allow custom subclasses of JobParent to be used in DslScriptLoader. So you can use your own JobParent with additional top-level methods. Would that help here?

          Daniel Spilker added a comment - damien_coraboeuf do you still need this? Do you need this for the seed plugin? I assume that you are using DslScriptLoader directly instead of the build step. With PR #984 I'm going to allow custom subclasses of JobParent to be used in DslScriptLoader . So you can use your own JobParent with additional top-level methods. Would that help here?

          Hi Daniel,

          Yes, we would definitely need this. As such, it has nothing to do with the Seed plug-in, only with the fact that we need to run some code, as part of the pipeline (re)generation, to take care of other provisioning activities. So having the possibility to extend JobParent in our plugins, and to do our our business would definitely help. Now, I do not know how this would fit if we do not create any actual job.

          Damien Coraboeuf added a comment - Hi Daniel, Yes, we would definitely need this. As such, it has nothing to do with the Seed plug-in, only with the fact that we need to run some code, as part of the pipeline (re)generation, to take care of other provisioning activities. So having the possibility to extend JobParent in our plugins, and to do our our business would definitely help. Now, I do not know how this would fit if we do not create any actual job.

          Yes, this will work when not creating any jobs. But why do you need to use DslScriptLoader when not using the DSL. Isn't it possible to use a plain GroovyScriptEngine instead?!?

          Daniel Spilker added a comment - Yes, this will work when not creating any jobs. But why do you need to use DslScriptLoader when not using the DSL. Isn't it possible to use a plain GroovyScriptEngine instead?!?

          We imagined to use a script which does several activities:

          • creation / update of jobs (and therefore using the DSL)
          • doing other activities (like provisioning of Artifactory & Ontrack)

          Of course, using a GroovyScriptEngine would make easy to run the last part, without any particular extension. Assuming the DSL JARs are in the classpath, plus all plugins contributing to it, would it work for the job generation part? Worth to test...

          Damien Coraboeuf added a comment - We imagined to use a script which does several activities: creation / update of jobs (and therefore using the DSL) doing other activities (like provisioning of Artifactory & Ontrack) Of course, using a GroovyScriptEngine would make easy to run the last part, without any particular extension. Assuming the DSL JARs are in the classpath, plus all plugins contributing to it, would it work for the job generation part? Worth to test...

            jamietanna Jamie Tanna
            damien_coraboeuf Damien Coraboeuf
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: