Provide a syntax for repeating a block with a Job configuration for each item in a list

[dtyler]

Here is one idea of how this could be done. It would generate a Release Stage multi-job with sub jobs for l1,f1, and d1.

In project.yaml

- project:
    name: sample-name
    jobs:
        - '{{project_name}}-Release-Stage':
            envList:
                - 'l1'
                - 'f1'
                - 'd1'

In Job-Release-Stage.yaml

builders:
    - multi_job:
        phases:
            'Deploys':
                jobs[envList as curEnv]:   # <- Here's the new bit
                    - name: '{{project_name}}-{{curEnv}}-Deploy'
                      current_params: true
wrappers:
    - timestamp: true
    - ansicolor: true

[crimsonknave]

I think this would be better served with something like this (more or less stolen from ansible):

- project:
    name: foo
    jobs:
        - '{{name}}-thing':
            with_overrides:
              - env: f1,
              - env: l1,
              - env: d1

That would take the job entry '{{name}}-thing' and execute it passing in each element of the array. That way the used job has the exact same syntax as if the jobs were declared not in a 'loop'. Would that still work for you?

[dtyler]

That would work just as well. I like include the name of the env I'm
deploying to in the job name, so being able to excluding it wouldn't be a
big win.

I had also imagined that this looping could be used as a crude form of
conditional by allowing an empty list of some kind. A separate solution to
that is probably more powerful than this looping bit is when it comes to
generalizing templates.
On Sep 17, 2014 2:28 PM, "Joseph Henrich" notifications@github.com wrote:

I think this would be better served with something like this (more or less
stolen from ansible):

• project:
  name: foo
  jobs:
  - '{{name}}-thing':
  with_overrides:
  - env: f1,
  - env: l1,
  - env: d1

That would take the job entry '{{name}}-thing' and execute it passing in
each element of the array. That way the used job has the exact same syntax
as if the jobs were declared not in a 'loop'. Would that still work for you?

—
Reply to this email directly or view it on GitHub
#26 (comment)
.

[AndrewHanes]

Do we want to append something to the job name similar to how PRs work? Otherwise we risk errors due to several jobs having the same name. Something like foo-env-{{env_val}}

[crimsonknave]

I think that the generator should raise an error if the names won't be unique. Or, at least if one of the passed vars isn't in the name. I'm not sure what would make sense to have it automagically add.

[AndrewHanes]

Won't having the user modify the name cause scoping issues (Or my idea of how scope works is incorrect for this)?

- project:
    name: foo
    jobs:
        - '{{name}}-thing-{{env}}':
            with_overrides:
              - env: f1,
              - env: l1,
              - env: d1

Env is undefined in the scope that {{name}}-thing-{{env}} is used, so the job {{name}}-thing-{{env}} cannot be referenced in the jobs section.

If we append to the name something like {{name}}-thing-{{override_key}}-{{override_value}} we can reference the job like the below snippet, similar to how the PR generators work:

- project:
    name: foo
    jobs:
        - '{{name}}-thing:
            with_overrides:
              - env: f1,
              - env: l1,
              - env: d1

But generated jobs would have the name foo-thing-env-f1, foo-thing-env-l1, foo-thing-env-d1

[crimsonknave]

The resolution happens in two parts. First the generator tries to find the job by the unresolved name, then it substitutes all the variables in. So, as long as the overrides are added to the variables by that point everything should work.

Currently, you should be able to override a variable thats in a name.

jobs:
  - '{{name}}-thing':
    name: first
  - '{{name}}-thing':
    name: second

That should work right now, the idea here would be to remove the duplication of having to specify the job more than once.