bitcrowd
Drop `#` in the defaults and rather add it to the adapters
I have lately seen that people use Tickety-tick with JIRA a lot with the commit configuration:
[{id}] {title}
rather than
[#{id}] {title}
This is because unlike github and gitlab, where issue link start with # in JIRA usually tickets start with a code like ABC-{number}. With the default setting, we are adding a # to commit names like this in JIRA [#ABC-123].
Sadly enough I noticed, that this breaks some nice automation. For example in the gitlab/jira integration everything works fine with [{id}] {title} while with the # the ticket numbers are not recognized properly. I am not sure, but I think this was not always the case. For example one of our former customers uses a custom made deployment tool (probably made before we changed this) which assumes [{id}] {title} without the # as well.
I know that we could fix this by using custom formats, but I would love to see that we move the # into the gitlab/github adapters, so that issues there are directly prepended with a # there, so we do not have the double prefix for JIRA. This should be fine, since branch names drop special chars in the id anyway (I guess). And will lead to the same result for github/gitlab but will greatly improve the flow for JIRA.
I am not so sure about notion.so/trello and how to handle things there though, but I wanted to ask about opinions here before I come up with an opinionated PR :)
What about we adjust the default template to drop the # from the subject line, but add Closes #{id}. in the commit message body for GitHub to automate closing of issues?
What do those other tools you mentioned look for? 🤔
Overall this looks like it'll be a breaking change and will require a major version bump. So although it's a tiny code change we might want to think about how to handle this.
What do those other tools you mentioned look for?
It seems that the gitlab-jira integration (built into gitlab) is fine with [EW-123] but breaks with [#EW-123] for example. As I said, the other tool is a custom made deployer tool of one of our former clients that are also actively using tickety-tick (👋 liefery) which still has the assumption JIRA tickets look like [SOME-123] instead of [#SOME-123] since old (ancient) versions of tickety tick were producing this afaik (they currently use a custom format to handle this).
Imho the # just does not make sense for JIRA.
Overall this looks like it'll be a breaking change and will require a major version bump. So although it's a tiny code change we might want to think about how to handle this.
true
What about we adjust the default template to drop the # from the subject line, but add Closes #{id}. in the commit message body for GitHub to automate closing of issues?
Same problem here. The gitlab integration will generate a Fixes EW-123 in the PR description on it's own when seeing ticket numbers in the commit message 🤷 .
Imho the # just does not make sense for JIRA.
Yeah 🤔 but making the # part of the ticket ID also feels wrong (we use it for other purposes where the # wouldn't work).
We could have a reference filter in the templates that formats the ID based on the adapter that produced the ticket and adds a # if it's github but it seems like a fair bit of additional complexity (the required information isn't currently added to the ticket).
We could just drop the # altogether and not change the adapters though. That would be a much easier change (albeit still breaking backwards compatibility).
still breaking backwards compatibility
I think that's the biggest blocker here 🪨. Looking at what Jira does (at least with the Gitlab integration), it seems to be able to link tickets perfectly fine even if one uses the # character in the name.
So I think the issue was kinda "fixed" by Jira itself. Therefore closing this, feel free to reopen if the problem persists 💌
With #372 thinking more about adapter specific fields will get more interesting again, so I will reopen this one as well. It still breaks the auto-closing of tickets btw (just linking works correctly). But we haven't used auto-closing at all in our projects because of other issues which will be resolved now.
Closing this again for now, as diving into the complexity of adapter specific fields and especially the difficulties of making all these breaking changes backwards compatible did not seem worth the effort for now.
We can of course always revisit the topic and I'm on board with any plans @andreasknoepfle 👯