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

Allow to test Job DSL scripts (simulation mode)

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • job-dsl-plugin
    • None

      Whenever Job DSL script is stored in a GitHub repository, it's impossible to use gitflow-like patterns to stage a change, verify pull-request and then merge.

      Naturally, you can't stage DSL script fully. However, you get 80% of the goal if:

      1. you can use GitHub Pull Request Builder
      2. you have a simulation mode turned on
      3. simulation mode runs DSL script, prints generated config files and/or changes but makes no changes to Jenkins configuration

          [JENKINS-27182] Allow to test Job DSL scripts (simulation mode)

          Arcadiy Ivanov added a comment - https://github.com/jenkinsci/job-dsl-plugin/pull/395

          Please have a look at the job-dsl-gradle-example. It shows how to set up a Gradle build for Job DSL scripts. That allows to compile and test any changes before committing them. It's also possible to use a Gradle build step before the "Process Job DSLs" step in a seed job to run any tests before updating the jobs and views. And the pull request builder can be configured to just execute the Gradle step to run the tests.

          Daniel Spilker added a comment - Please have a look at the job-dsl-gradle-example . It shows how to set up a Gradle build for Job DSL scripts. That allows to compile and test any changes before committing them. It's also possible to use a Gradle build step before the "Process Job DSLs" step in a seed job to run any tests before updating the jobs and views. And the pull request builder can be configured to just execute the Gradle step to run the tests.

          Arcadiy Ivanov added a comment - - edited

          This is great. Is there a reason why the testing functionality should not be added into the Job DSL plugin?

          There are several problems with the above approach that you're referencing:

          1. Large overhead to setup tests, considering Groovy and Job DSL are already on Jenkins
          2. Requirement to install Gradle on master (even if via wrapper)

          The proposed PR, while not running Spock, adds a single checkbox that turns the simulation mode on and allows to inspect the generated results. MemoryJobManagement doesn't do that and it's a tall order to have a person setting up jobs to be proficient in Spock to begin with.

          It still would be great to add an ability to run Spock Specs in simulation mode as well, but would require adding Spock as a dependency to Job DSL. If this is acceptable I can add such capability to the plugin as well.

          Arcadiy Ivanov added a comment - - edited This is great. Is there a reason why the testing functionality should not be added into the Job DSL plugin? There are several problems with the above approach that you're referencing: Large overhead to setup tests, considering Groovy and Job DSL are already on Jenkins Requirement to install Gradle on master (even if via wrapper) The proposed PR, while not running Spock, adds a single checkbox that turns the simulation mode on and allows to inspect the generated results. MemoryJobManagement doesn't do that and it's a tall order to have a person setting up jobs to be proficient in Spock to begin with. It still would be great to add an ability to run Spock Specs in simulation mode as well, but would require adding Spock as a dependency to Job DSL. If this is acceptable I can add such capability to the plugin as well.

            arcivanov Arcadiy Ivanov
            arcivanov Arcadiy Ivanov
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: