Store and track externally imported issue identifier

I think we should consider tracking externally imported issue identifier.

Reposting @amirkdv note from &2738 (comment 305070029) here for context. Thank you @amirkdv for contributing and raising the issue.

Further in my explorations, I have identified the following challenge which, if unresolved, might be a deal-breaker for some users: maintaining cross references between issues and commits. I see only one viable path involving git history rewrites which is quite undesirable, esp if one has artifacts (e.g. docker images) that are tagged with git versions. Can you folks let me know if I'm missing something?

Context

The needs for issue <-> commit cross-referencing are:

• issue → commit: see all the commits pertaining to a particular issue.
• commit → issue: see the rationale/thinking/need behind a commit by looking at the issue it refs in its message.

If you use JIRA for issues and GitLab for code:

• issue → commit: you have JIRA issue ids like PRJ-123 and enforce a commit message template that starts with things like jazz it up, refs PRJ-123. And you presumably have some sort of git integration which allows you to see all such commits in the JIRA page for PRJ-123.
• commit → issue: non-existent.

One of the biggest appeals of having issues and code in the same place (i.e. GitLab) is much better integration of these cross-references.

Problem

When importing any non-trivial project from JIRA, one would really like to maintain these relationships for existing issues/commits. However, GitLab does not allow issue iids to be things like PRJ-123; I get an 400: iid is invalid when I try.

Solution?

The only viable alternative I can think of involves:

• set the iid for the imported issue to the integer portion of the JIRA id, i.e. PRJ-123 becomes 123.
• perform a wholesale git history rewrite (with things like git filter-repo) to automatically enforce the string replacement s/PRJ-(\d+)/#\1/ in all commit messages, so that jazz it up, refs PRJ-123 becomes jazz it up, refs #123

This has the undesirable consequence that it changes all commit SHAs. Now, this could be the price of "doing business" if the only issue was coordinating among team members to update their local copies according to the rewritten history. Where it becomes problematic is if one has been using commit SHAs as part of the versioning scheme for various artifacts (e.g. docker images), as we do. For example, the commonly used git describe --tags produces labels like v5.1-7-g7e79255 where v5.1 is a git tag (can be preserved through history rewrite), 7 is the number of commits since tag (preserved through history rewrite), and 7e79255 is the first digits of the commit SHA (lost in history rewrite).

Question

Is there a better way or should we just accept either broken cross-references or broken artifact labels, as a price of migrating our current issues to GitLab?

• Store external issue identifier in issues table ?
• Have a separate table for tracking externally imported issues identifiers ?
• Would we only use the identifiers to link to gitlab issues ?
• Would tracking these facilitate parsing of the description and comment references ?

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.