When issuing newa manually it may be handy to use an existing Jira issue instead of creating a new one. Since there could be multiple items defined in the Jira issue config file the best approach seems to utilize issue IDs defined in a config file and provide a mapping to Jira issues on a command line as a parameter of jira subcommand. If existing Jira issue is provided, the respective item won't attempt to search or create an old issue in Jira and use the provided one instead.
E.g. for the config file snippet
- summary: "Testing ER#{{ ERRATUM.id }} {{ ERRATUM.summary }} ({{ERRATUM.release}})"
description: "Epic tracking all work on errata related to a specific release."
assignee: '{{ ERRATUM.people_assigned_to }}'
type: epic
id: errata_epic
on_respin: keep
When issuing newa manually it may be handy to use an existing Jira issue instead of creating a new one. Since there could be multiple items defined in the Jira issue config file the best approach seems to utilize issue IDs defined in a config file and provide a mapping to Jira issues on a command line as a parameter of
jira
subcommand. If existing Jira issue is provided, the respective item won't attempt to search or create an old issue in Jira and use the provided one instead.E.g. for the config file snippet
one could run