Parameters usage in bash script

[dauphinpasdroit]

Hello,

I encountered an issue regarding the parameters usage into a bash script.

First, here is the configuration pipeline file:

format_version: 10
pipelines:
  windowsAzure:
    group: serverDeployment
    label_template: ${COUNT}
    lock_behavior: none
    display_order: -1
    materials:
      git:
        git: <<redacted>>
        shallow_clone: false
        auto_update: false
        branch: main
    stages:  
    - preconfig:
        fetch_materials: true
        keep_artifacts: false
        clean_workspace: false
        approval:
          type: success
          allow_only_on_success: false
        jobs:
          preConfig:
            elastic_profile_id: eaProd
            tasks:
            - exec:
                command: /bin/bash          
                arguments: 
                - ./pipelines/deployVm/windowsAzure/jobs/preConfig/preConfig.sh
                run_if: passed
    - infrastructureDeployment:
        fetch_materials: true
        keep_artifacts: false
        clean_workspace: false
        approval:
          type: success
          allow_only_on_success: false
        jobs:
          infrastructureDeployment:
            elastic_profile_id: eaProd
            tasks:
            - exec:
                command: /bin/bash          
                arguments: 
                - ./pipelines/deployVm/windowsAzure/jobs/infrastructureDeployment/terraform.sh
                run_if: passed
    parameters:
      region: ""
      vm_size: ""
      domain_name: ""
      packer_image: ""
      azure_location: ""
      affiliate: "MEA"
      server_role: "APP"
      environment: "PROD"
      snakeid: ""
      patching: ""
      monitoring_emea: ""
      application: "GoCD"
      backup_policy: ""
      subscription: ""

And here is the bash script I use in the first job (preconfig):

#!/bin/bash
echo #{affiliate}
APPLI=${#{application}// /-}
az login --service-principal -u ${ARM_CLIENT_ID} -p ${ARM_CLIENT_SECRET} --tenant ${ARM_TENANT_ID}
az account set --subscription ${ARM_SUBSCRIPTION_ID}
az group create -l ${AZURE_LOCATION} -n "{affiliate}-{APPLI^^}-{ENVIRONMENT^^}"
ansible-galaxy collection install netbox.netbox
ansible-galaxy collection install azure.azcollection
python3 ./pipelines/deployVm/windowsAzure/jobs/preConfig/vmName.py

I think I didn't miss something in the usage of parameters into a pipeline. We can use a parameters value anywhere into a pipeline or a script using #{paramsvalue} right ?

How can I avoid the bash script to consider the # as a comment charactere ?

I tried using escape charactere like this : \#{affiliate} but it doesn't work neither.

Maybe I missed something into the documentation regarding this subjects, but I still don't understand how to use it...

Thank you for your help

[chadlwilson]

You can't use GoCD pipeline parameters within the content of a separately source controlled shell script outside the pipeline configuration.

GoCD can only replace parameters within job configuration it knows about at "trigger time", not something within source control or an artifact sourced by the agent at runtime.

Presumably ./pipelines/deployVm/windowsAzure/jobs/preConfig/preConfig.sh is source controlled or from an artifact.

The shell script argument to bash has no special meaning to GoCD, it doesn't even know it's a file it 'could' look inside - it's just a string it passes to bash when forking a process within the agent.

If you want to supply variables to a shell script at runtime, you'd need to use either

• env variables (populated either directly, or indirectly from the parameters) with the script expects to have available
• or supply the parameter values in args to the script when invoking via bash, i.e inside arguments:

Most folks will probably use env vars I imagine.

[chadlwilson]

Probably more relevant than that, parameters are specifically used with pipeline templates ( https://docs.gocd.org/current/configuration/admin_use_parameters_in_configuration.html ) which is a different concept that doesn't have support with 'pipelines as code' (the template has to be specified in the UI or via API call).

When working with pipelines as code like the above env vars, or some other approach to generate/template the pipeline config yaml/json is typically employed.

TL:DR - for your use case pipeline 'parameters' are probably not what you want :)

[dauphinpasdroit]

Hey, thank you for the quick answer, appreciate it.

I guess I'll stick with env var for my use case. Thank you for all the explanations !

[chadlwilson]

If you want to dig a bit deeper into why the pipelines-as-code doesn't have support for pipeline templates (directly) there is a long discussion at tomzo/gocd-yaml-config-plugin#2 and related GoCD issues.