add params.branch to in/get for use in an "across" step

[Houlistonm]

use case:

jobs:
  - name: set-feature-pipelines
    plan:
      - in_parallel:
          - get: automation-image
            params:
              unpack: true
          - get: ytt
            params:
              globs:
                - ytt-linux-amd64
          - get: cli-tool-feature-branches
            trigger: true
      - load_var: branches
        file: cli-tool-feature-branches/branches.json
      - across:
          - var: branch
            values: ((.:branches))
        do:
        - get: cli-tools
          trigger: true
          get_params:
            branch: ((.:branch.name))
        - task: render-pipeline
          image: automation-image
          file: cli-tools/ci/tasks/render-ytt/task.yml
          params:
            YTT_FLAGS: |
              -f cli-tools/ci/cli_tools.yml
              -f cli-tools/ci/cli_tools_vars.yml
        - set_pipeline: package-cli-tools
          file: ytt-output/output.yml
          instance_vars: {feature: ((.:branch.groups.feature))}
          vars: {branch: ((.:branch.name))}

[taylorsilva]

cool butttttt this kinda breaks the contract that resource-types have with Concourse. The get step is always given a specific version to fetch. In this case, it's always a commit sha. If that commit sha isn't on that branch then the get step will fail. I don't think it makes sense for us to merge this into the resource.

[Houlistonm]

I understand the contract. But this is different.
We're trying to set a new pipeline based on the branch name which the resource has already discovered prior to reaching this step.

If you're firm about not/unable to accept this PR, can you propose an alternate solution to set multiple pipelines across feature branches w/o resorting to ytt or some other external tool?

[taylorsilva]

Leaving this open still because I do like the idea, but I don't like the way it goes against the resource-types contract. I agree that doing something like this would make this workflow WAY easier to achieve. I just don't like the behavioural change it makes to the resource.

[taylorsilva]

I'd probably create a task that would do the git checkout to the other branch.

jobs:
  - name: set-feature-pipelines
    plan:
      - in_parallel:
          - get: automation-image
            params:
              unpack: true
          - get: ytt
            params:
              globs:
                - ytt-linux-amd64
          - get: cli-tool-feature-branches
            trigger: true
          - get: cli-tools
            trigger: true
      - load_var: branches
        file: cli-tool-feature-branches/branches.json
      - across:
          - var: branch
            values: ((.:branches))
        do:
        - task: switch-branch
          image: automation-image
          file: cli-tools/ci/tasks/switch-branch/task.yml
          input_mapping:
            repo: cli-tools
          output_mapping:
            repo: cli-tools
          params:
            # Git auth info here if required (ssh key/username/password)
            branch: ((.:branch.name))
        - task: render-pipeline
          image: automation-image
          file: cli-tools/ci/tasks/render-ytt/task.yml
          params:
            YTT_FLAGS: |
              -f cli-tools/ci/cli_tools.yml
              -f cli-tools/ci/cli_tools_vars.yml
        - set_pipeline: package-cli-tools
          file: ytt-output/output.yml
          instance_vars: {feature: ((.:branch.groups.feature))}
          vars: {branch: ((.:branch.name))}