<commit_before>When you get a little bit expert in your usage of the Job DSL and Plugin, you might want to try the following Power Moves:

# Run a DSL Script locally
Before you push a new DSL script to jenkins, it's helpful to run it locally and eyeball the resulting XML. To do this follow these steps:

1. git clone https://github.com/jenkinsci/job-dsl-plugin.git
1. cd job-dsl-plugin
1. ./gradlew :job-dsl-core:oneJar
1. DSL_JAR=$(find job-dsl-core -name '*standalone.jar'|tail -1)
1. java -jar $DSL_JAR sample.dsl.groovy

If you already have the source code checked out then you can ignore step 1.

What's going on here is that there's a static main method that can run the DSL, you just have to give it a filename. It'll output all the jobs' XML to the current directory. Likewise, if you use "using" (the templates-like feature) it'll look in the current directory for a file with the name of the job appended with ".xml" at the end of it.

By default the current directory is added to the classpath to be able to import classes. When using sub-directories for
scripts, the classpath differs compared to running in Jenkins where the DSL script's directory is added to the
classpath. Add the `-j` command line option to use the same behavior as when running in Jenkins:

    java -jar $DSL_JAR -j sample.dsl.groovy

# Generate a Job config.xml without having to fire up Jenkins
1. Add some job dsl content to a file, say job.dsl
1. Run the gradle command:  ./gradlew run -Pargs=job.dsl

   Note: the run task loads the file relative to the job-dsl-core directory, so I always just put my test files in there.
   Note2: if your dsl code contains a job named "myJob", the run task will generate myJob.xml.

[The original discussion about this on the Newsgroup](https://groups.google.com/forum/#!msg/job-dsl-plugin/lOYH7bL7AcM/70N1AEW219cJ)

# Access the Jenkins Environment Variables
To access the Jenkins Environment variables (such as BUILD_NUMBER) from within DSL scripts just wrap them in '${}'. E.g.:

`println " BUILD_NUMBER = ${BUILD_NUMBER}"`<commit_msg>simpler steps to run DSL scripts locally<commit_after>When you get a little bit expert in your usage of the Job DSL and Plugin, you might want to try the following Power Moves:

# Run a DSL Script locally
Before you push a new DSL script to Jenkins, it's helpful to run it locally and eyeball the resulting XML. To do this follow these steps:

    curl -O https://repo.jenkins-ci.org/public/org/jenkins-ci/plugins/job-dsl-core/@version@/job-dsl-core-@version@-standalone.jar
    java -jar job-dsl-core-@version@-standalone.jar sample.dsl.groovy

Replace the version number with the version of Job DSL that's installed in Jenkins to get comparable results. If you
already have downloaded the JAR then you can ignore step 1.

What's going on here is that there's a static main method that can run the DSL, you just have to give it a filename. It'll output all the jobs' XML to the current directory. Likewise, if you use "using" (the templates-like feature) it'll look in the current directory for a file with the name of the job appended with ".xml" at the end of it.

By default the current directory is added to the classpath to be able to import classes. When using sub-directories for
scripts, the classpath differs compared to running in Jenkins where the DSL script's directory is added to the
classpath. Add the `-j` command line option to use the same behavior as when running in Jenkins:

    java -jar job-dsl-core-@version@-standalone.jar -j sample.dsl.groovy

# Generate a Job config.xml without having to fire up Jenkins
1. Add some job dsl content to a file, say job.dsl
1. Run the gradle command:  ./gradlew run -Pargs=job.dsl

   Note: the run task loads the file relative to the job-dsl-core directory, so I always just put my test files in there.
   Note2: if your dsl code contains a job named "myJob", the run task will generate myJob.xml.

[The original discussion about this on the Newsgroup](https://groups.google.com/forum/#!msg/job-dsl-plugin/lOYH7bL7AcM/70N1AEW219cJ)

# Access the Jenkins Environment Variables
To access the Jenkins Environment variables (such as BUILD_NUMBER) from within DSL scripts just wrap them in '${}'. E.g.:

`println " BUILD_NUMBER = ${BUILD_NUMBER}"`
{'fraction_non_alphanumeric': 0.06818181818181818, 'fraction_numerical': 0.007029053420805998, 'mean_word_length': 4.004689331770223, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 6}, 'pii_count': 3, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7625267', 'n_tokens_mistral': 1283, 'n_tokens_neox': 1203, 'n_words': 643}