Allow system variables for endpoint, user, login & project in config.yml

[vanniktech]

Ideally I'd like to configure defaults for endpoint, user, login & project like this:

endpoint: $JIRA_ENDPOINT
user: $JIRA_USER
login: $JIRA_LOGIN
project: $JIRA_PROJECT

Currently that's not possible though. My motivation behind this is that I want to upload my configuration file on Github but not expose any 'sensitive' information.

For custom commands this already does work:

custom-commands:
  - name: qa
    help: assigns the given ticket to qa
    options:
      - name: assignee
        short: a
        default: $JIRA_DEFAULT_QA_ASSIGNEE
    args:
      - name: ticketnumber
        required: true
    script: |-
      {{jira}} assign {{args.ticketnumber}} {{options.assignee}}

[coryb]

Generally I recommend putting endpoint, user and login in your $HOME/.jira.d/config.yml. Then in your project workspace at ./.jira.d/config.yml you would have project and custom-commands. go-jira will merge all the .jira.d/config.yml if finds in your path heirarchy.

[vanniktech]

Those are already in $HOME/.jira.d/config.yml. However I've got my home directory open source and hence would like to push it.

With environment variables I could have different configurations based on the computer I'm working on.

[coryb]

I see, there is a template function like {{env "JIRA_USER"}} but that is currently only available in the input/output templates, not in the config.yml file. I can look at adding that support when I get time. You can use an executable config.yml, I am not fond of this mechanism, but for now I think it is the only thing that will work. If the config.yml is executable go-jira will try to execute it and then parse the STDOUT as yaml. So something like this should work:

#!/bin/sh
cat <<EOM
endpoint: $JIRA_ENDPOINT
user: $JIRA_USER
login: $JIRA_LOGIN
project: $JIRA_PROJECT
EOM

[vanniktech]

Yeah I've also thought about the executable config file and I agree with you that this mechanism isn't really the best. Especially when having multiple custom commands.

Adding support for environment variables in the config file seems like a good solution.

[vanniktech]

Gentle nudge on this. Has there been any progress? Happy to help out.

[coryb]

I have spent some time on this and have not come up with any good solutions. It is a rather complex to re-evaluate how configuration properties are processed (and merge with command line arguments).

I have a similar problem with another project I maintain, so I will try to find a solution for both projects, but I am not sure how long it will take. I have very little time these days.

For now I still recommend the executable config files, you can apply configuration per custom command with this solution as well by creating $HOME/.jira.d/<command>.yml that is executable. As long as the file emits YAML, it should work.

[vanniktech]

I don't want to create those executable yml files for every possible command that I want to use though.

Environment variables could have the least priority. Would that make things easier?

[BorysDrozhak]

the problem with executable yml that second arguments, like for example: jira epic add will not work. There is no mechanism to create a config for them.