Template front end

[abutcher-gh]

Potentially relevant to #2, though it's more of a idea to throw out there; I'm not sure it's exactly what was intended.

It's working well for us and supports the user's choice of templating engine. Indeed, they could choose to use (or combine from different sources in one configrepo) different templating engines.

The only requirement is that you have a script or program to process files with a user-defined naming pattern.

Example

Example config: (mustache.gocd-yaml-generator.yaml)

generators:
  mustache-inline:
    pattern: '**/*.gocd.mi.yaml'
    script: |
      mustache-inline "{{file}}"

Example input: (test.gocd.mi.yaml)

---
branches:
    - name: master
    - name: demo
---
pipelines:
  {{#branches}}
  mcu-firmware.{{name}}:
    group: stuff
    label_template: "mcu-firmware-{{name}}.${COUNT}"
    materials:
      mcu-firmware:
        git: http://my-server/git/mcu-firmware
        branch: {{name}}
    stages:
      - build:
          clean_workspace: true
          artifacts:
           - build:
               source: out/mcu-firmware-*
               destination: mcu-firmware
          tasks:
           - script: |
              PATH="/usr/local/crosstool/gcc-arm-none-eabi-7-2018-q2-update/bin:$PATH"
              sh ./build.sh
  {{/branches}}

Note the file does not have to be combined (data and template) as the example above shows. That was just convenient for demo.

Usage of "inclusion" within the chosen templating engine would allow the instantiating file to specify the data and a reference to the template to use. With mustache something similar to

---
branches:
    - name: master
    - name: demo
---
pipelines:
  {{#branches}}
  {{> first-pipeline}}
  {{> second-pipeline}}
  {{/branches}}

Where first-pipeline.mustache and second-pipeline.mustache are local templates for particular pipelines. They inherit the scope of the branches "loop" (i.e. can use name in this case).

I think this strategy gives a lot of flexibility. I just wanted to put it out there to see if there was any interest in getting it (or something similar) merged into the main plugin.

[tomzo]

Hi,

Thanks a lot. I really like the concept. This isn't exactly templates as in #2 because here, input parameters and templates have to be in the same repository. But I see how it is a powerful tool.

I think this strategy gives a lot of flexibility. I just wanted to put it out there to see if there was any interest in getting it (or something similar) merged into the main plugin.

I was thinking of something like it. generators seems like a good name.
If I understand correctly you use it when yaml references are not enough, e.g. to generate same pipeline for each branch like in the demo.

I am not sure if relying on having a pre-installed tool on server is correct approach. Usually GoCD plugins don't do that. I would rather support explicitly some template engines, using library such as jmustashe or jinjava