Perry Hoekstra
Perry Hoekstra

Reputation: 2763

Jenkins Job Builder: Project Level Variables

Within JJB, you can define project-level variables like this:

- defaults:
    name: global
    git_url: "git@....."

- project
    name: some-test
    jobs:
      - test-{name}

- job-template
    name: test-{name}
    scm:
      - git:
          url: "{git_url}"
          branches:
            - master

My question, must I hardcode the value of git_url at the default level or can I use some JJB mechanism to bring that in at job load/execution?

The reason I ask is that the yaml script that contains these JJB jobs can be used to define TEST, QA and PROD. It would be nice to just point at a properties file that contains the value for git_url and any other global variable values. I took a look at: http://docs.openstack.org/infra/jenkins-job-builder/definition.html?highlight=default#defaults and I did not see any mechanism.

Upvotes: 3

Views: 2791

Answers (1)

Wayne Warren
Wayne Warren

Reputation: 86

If I understand your question correctly, there are two other approaches available within the context of a single yaml file

Approach 1: Set git_url at the project level

- project
    name: some-test
    git_url: "[email protected]:woof/bark.git"
    jobs:
      - test-{name}:

- job-template
    name: test-{name}
    scm:
      - git:
          url: "{git_url}"
          branches:
            - master

Here git_url is set at the project level. This approach allows you to define a second project with a different value for git_url, ie

- project
    name: some-other-test
    git_url: "[email protected]:meow/meow.git"
    jobs:
      - test-{name}:

Approach 2: Set git_url at the job-template instance level

- project
    name: some-test
    jobs:
      - test-{name}:
        git_url: "git@....."

- job-template
    name: test-{name}
    scm:
      - git:
          url: "{git_url}"
          branches:
            - master

Here git_url is set on the actual instance of the job-template where it is specified. If your job-template had more than just {name} in its name, this would allow you to create multiple instances of it in the list of jobs at the project level, ie

- project
    name: some-test
    git_url: "git@....."
    jobs:
      - test-{name}-{type}:
        type: 'cat'
      - test-{name}-{type}:
        type: 'dog'

- job-template
    name: test-{name}-{type}
    display-name: 'Test for {type} projects'
    scm:
      - git:
          url: "{git_url}"
          branches:
            - master

Thoughts on TEST vs QA vs PROD

You also mentioned that you would like some kind of external properties file to differentiate between TEST, QA, and PROD environments. To address this let's consider four different files, project.yaml, defaults/TEST.yaml, defaults/QA.yaml, defaults/PROD.yaml whose contents are enumerated below.

project.yaml

- project
    name: some-test
    jobs:
      - test-{name}:

defaults/TEST.yaml

- defaults:
    name: global
    git_url: "[email protected]:woof/test.git"

defaults/QA.yaml

- defaults:
    name: global
    git_url: "[email protected]:woof/qa.git"

defaults/PROD.yaml

- defaults:
    name: global
    git_url: "[email protected]:woof/prod.git"

Okay so these aren't great examples because you probably wouldn't have a different git repository for each environment, but I don't want to complicate things by straying too far from your original example.

With JJB you can specify more than one YAML file on the command line (I don't want to complicate the example or its explanation, but you can also specify directories full of JJB yaml). To differentiate between TEST, QA, and PROD deployments of your Jenkins job you can then do something like:

jenkins-jobs project.yaml:defaults/TEST.yaml

For your test environment.

jenkins-jobs project.yaml:defaults/QA.yaml

For your qa environment.

jenkins-jobs project.yaml:defaults/PROD.yaml

For your prod environment.

Hope that helps.

Upvotes: 7

Related Questions