I am trying to pass the
<< pipeline.git.branch >> as a parameter to a command. This works great until someone pushes a tag to the repo.
The command is defined as follows:
description: The field of the json file to set
description: The value to set the field to
- run: ...
And I am using it like this:
value: "<< pipeline.git.branch >>"
<< pipeline.git.branch >> is empty (when a tag triggers the pipeline), the config fails with the following message:
Error calling workflow: 'generate-config'
Error calling job: 'gomplate/render-config'
Error calling command: 'vfcommon/set-json-string'
Unknown variable(s): value
I have tried using single-quotes, double-quotes, and no quotes. My desired behaviour would be for it to just pass it as the empty string. Any idea how I could achieve this? I believe that this is a bug, but it might be intended behaviour that I just don’t understand.
If you are using the voiceflow/common orb (which I am guessing you are) the first port of call would be to let the orb maintainer that they have an edge case issue that they need to address within their code base. From a quick look at the orb code the issue is caused by the fact that no default value is expressed to deal with the type of issue you are seeing and there is no checking to see if a value has been pasted.
The one thing you can do within your config.yml file is use when: with a pattern match so that the job is only executed if pipeline.git.branch causes a positive match. The starting point to understand this feature is
The use of a branch-based filter may also be an option, but using when: would I think result in a cleaner code.
Thanks for the comprehensive answer! I happen to be the author of the
voiceflow/common orb, so my primary question boils down to why
"<< pipeline.git.branch >>" resolves to
"". I believe this is a bug, but I may be mistaken. I won’t mark your reply as a solution, as it doesn’t address this question, but it is still very helpful nonetheless!
I can not say that
"<< pipeline.git.branch >>" resolving to basically null when a tag is defined is a bug, rather it seems to be a well-known ‘feature’ as the circleci script processor seems to consider them mutually exclusive for some reason.