feat(merge-versions): display link to target version

[bblancha]

As a user of the octobot version page, I often want to copy a link
to the project version I have just created, in order to paste that
link into other work tracking tools.

This change adds a link to the newly-created version in the success
message, or adds a link to the previously-existing version if it already
existed.

Also: we were previously showing the "Success: ..." message even when
the merge-versions request failed. Now we do not transition to the success
message in error cases.

[rcorre]

LGTM, aside from the warning about the unnecessary return.

[rcorre]

Just a thought -- I use a bash script to hit the octobot API from the CLI.
Instead of returning the version ID from the API and building the URL in JS, returning the version URL from the API would help me out as well.

Admittedly my use is probably weird/not supported (and it wouldn't be hard for me to do the same url building)

[trevershick]

Just a thought -- I use a bash script to hit the octobot API from the CLI. Instead of returning the version ID from the API and building the URL in JS, returning the version URL from the API would help me out as well.

Admittedly my use is probably weird/not supported (and it wouldn't be hard for me to do the same url building)

Share CLI please @rcorre . I'd love to not have to go into the web UI

[bblancha]

on building the URLs in the service or not:
I was imitating the way it did it for the links to the issues.

It makes sense to me to return the whole link, but would like to understand first if there was a hard and fast reason that the issue links were built in the client.

@matthauck do you happen to remember if it matters whether the Issue links are built in the client or on the server side?

[matthauck]

unsure about the case where the version already exists. otherwise, lgtm!

[matthauck]

@matthauck do you happen to remember if it matters whether the Issue links are built in the client or on the server side?

I could go either way. Constructing the whole URL in the service rather than the front-end might be nice, but since jiraBase, etc. is already there, this way works too.

[matthauck]

also: @rcorre's comment about better support for CLI support is a good reason also to move the url construction into the service. Less code in the front-end -> more extensibility? 🎉

[bblancha]

[bblancha]

fixes #378