Import JIRA project issues into GitLab project issues
Description
- Import issues from a JIRA project into a GitLab project.
- This feature is only available (as a button, or whatever UI), once you have already set up our existing JIRA project service integration. So that way, we don't have to mess with any weird project set up design / tech things in this issue. The assumption is that the integration is already there and we are building on our existing base.
- So for a qualified GitLab project, anytime you can go into some menu, click a button (or some UI), and then it just dumps a copy of all the JIRA issues into GitLab issues. Again it is stateless and not idempotent.
- There is some transactional process to copy all issues from the JIRA project and create new corresponding issues into the GitLab project.
- If the GitLab project has any existing issues, they are unchanged in this process.
- If there is any error, everything is rolled back, so that you cannot have partial copies after the process.
- The process is not idempotent. So if you run the process twice immediately, you will have two copies of the JIRA issues in the GitLab project.
- There is no state maintained. After you have done the import, both JIRA and GitLab are not aware that it was done. Certainly there is no linkage or synching between issues in the two systems.
MVC Target Data
Initial MVC
- For each JIRA issue in the JIRA project, create a corresponding issue in the GitLab project, with these mappings:
- JIRA issue summary -> GitLab issue title
- JIRA issue description -> GitLab issue description
- Simplified text handling/conversion
- GitLab issue author := GitLab user who activates this import process.
- All other fields and attributes in the GitLab issue are set to as if it was created in the GitLab web UI with nothing beyond the above selected. E.g. the issue is in open state and there are no labels associated.
Follow-up Iterations (a.k.a. what the MVC doesn't do)
- Add comment on behalf of importer with information about the import / meta-data
- Add support for user mapping
- Add support for importing comments
- Add support for importing attachments
- Add support for importing sub-tasks as issues and setting them as dependents on the parent issue
- Add support for importing labels
- Add support for importing weight
- Add support for importing due date
- Add support for importing Epics
- Add support for importing epic and issue dependencies
- Add support for importing both open and closed issues
- Add support for more granularly specifying which issues to import via label, status, or JQL query.
- Add support for mapping custom fields to labels and/or append description with table of
key:value
- Generate traceability report to demonstrate input and output and that there was no data loss.
Issues
{
title: JIRAIssue.fields.summary,
description: JIRAIssue.fields.description,
labels: [JIRAIssue.fields.issuetype.name],
created_at: JIRAIssue.fields.created,
updated_at: JIRAIssue.fields.updated,
done: issue.fields.status.statusCategory.name === 'Done' ? true : false,
assignee: jiraToGitlabUser(JIRAIssue.fields.assignee ),
reporter: jiraToGitlabUser(JIRAIssue.fields.reporter),
comments: JIRAComments.map(JIRAComment => ({
author: jiraToGitlabUser(JIRAComment.author),
comment: JIRAComment.body,
created_at: JIRAComment.created
})),
attachments: JIRAAttachments.map(JIRAAttachment => ({
author: jiraToGitlabUser(JIRAAttachment.author),
filename: JIRAAttachment.filename,
content: JIRAAttachment.content,
created_at: JIRAAttachment.created
}))
};
Epics (Next Gen Only)
TBD
Original proposal
As a user, I want to import existing issues from JIRA to GitLab so that I can switch from JIRA to GitLab as my ticketing system. The import would include:
- issue title
- issue comments
- current issue state (if not all states through the issue's history)
- attachments
- current assignee (if not all assignees through the issue's history)
- Related migration tool created by the Professional Services team
- Related import script
- Related import script
- Guest blog post
Links & References
Proposed Design
This is a bit outdated and may need to be revisited before implementation:
Edited by Gabe Weaver