Follow-up from #238.
The JIRA link template used by the bot to generate "Additional WildFly Issue Links Found..." sections in PR descriptions is currently hardcoded in RuntimeConstants.java:
public static final String BOT_JIRA_LINK_TEMPLATE = "https://redhat.atlassian.net/browse/%1$s";
If the JIRA domain changes again (as it did from https://issues.redhat.com -> https://redhat.atlassian.net), a code change + redeployment is required. This should instead be configurable via wildfly-bot.yml config file (no redeployment would be necessary), with a sensible default fallback (?).
So we would have something like:
wildfly:
projectKey: "WFLY" # optional (?), and should probably be project_key (snake case)
issueTrackerLink: "https://redhat.atlassian.net/browse" # new and optional (?), and should probably be issue_tracker_link (snake case)
# ...
One note: I am not 100% sure how I feel about these two options being optional. Would it not be better to make these fields explicit, so that these behavior features are not so dependent on the wildfly-github-bot project rather than the actual wildfly-bot.yaml config file?
Another thing we might consider is whether including an "issue tracker link" would make the current simple nature of coarse grain too complicated--since all WILDFLY-related repos are expected* to be part of the same JIRA domain, the current BOT_JIRA_LINK_TEMPLATE has one advantage in this regard. However, I think the above notes could outweigh this advantage.
*) Not to be too pedantic, but in theory, the opposite could still happen (two (or more) WF/EAP related projects with different JIRA domains).
Follow-up from #238.
The JIRA link template used by the bot to generate "Additional WildFly Issue Links Found..." sections in PR descriptions is currently hardcoded in RuntimeConstants.java:
If the JIRA domain changes again (as it did from https://issues.redhat.com -> https://redhat.atlassian.net), a code change + redeployment is required. This should instead be configurable via
wildfly-bot.ymlconfig file (no redeployment would be necessary), with a sensible default fallback (?).So we would have something like:
One note: I am not 100% sure how I feel about these two options being optional. Would it not be better to make these fields explicit, so that these behavior features are not so dependent on the
wildfly-github-botproject rather than the actualwildfly-bot.yamlconfig file?Another thing we might consider is whether including an "issue tracker link" would make the current simple nature of coarse grain too complicated--since all WILDFLY-related repos are expected* to be part of the same JIRA domain, the current
BOT_JIRA_LINK_TEMPLATEhas one advantage in this regard. However, I think the above notes could outweigh this advantage.*) Not to be too pedantic, but in theory, the opposite could still happen (two (or more) WF/EAP related projects with different JIRA domains).