The Git Integration for Jira app is packed with features that makes Jira administrators and developers happy. However, with different hardware configurations out there, these great features can also become burdened by issues.
Below are the Git Integration app known issues and workarounds:
Number of connected repositories per integration
The Git Integration for Jira app have per integration limitation for number of connected repositories:
- GitHub – 5000
- GitLab – 5000
- All others – 5000
Reference: GITCL-1395, GITCL-1846
2GB object Git repositories storage limit
The Git Integration for Jira application uses the JGit library which does not support objects over 2GB in size stored in git repositories.
- 2GB object limit
Smart commits failing user search by email
It was reported that some users have their smart commits attributed to the app user rather than specific users. It is found that the user search via email is failing. Some Jira Cloud instances are failing to return users based on email.
/rest/api/2/user/assignable/search?issueKey=ABC-123 to return a list of assignable users for an issue – if the user search by email fails.
Microsoft pull request requirement for status updates
Microsoft integrations require all pull requests for the configured repositories to be requested each time for status updates. Microsoft’s Pull Request APIs do not currently provide any information allowing for filtering by last changed date/time.
Why Microsoft PAT integrations require "All accessible organizations" permission
It is highly required that administrators must select the "All accessible organizations" option when creating personal access tokens (PAT). Otherwise, the integration will not work.
Please follow the instructions for creating MS/Azure PATs outlined in our Confluence how-tos here.
For more information, see the official reference for Azure DevOps PAT integration.
SSH single Git repository integration is not generating the trigger for Jira Automation
In Automation for Jira, a user can create a rule or set of rules to start a trigger. These triggers will run the rules while listening to events; such as when a commit or branch is created.
This feature works well for auto-connected integrations and single HTTPS authenticated git repositories, but single repositories authenticated via SSH connection are not supported by Atlassian Jira Cloud (Atlassian bug issue: JSWCLOUD-20935).
If you use Jira automation triggers, we strongly recommend to use HTTP/HTTPS connections for single repository git URL. (See below)
| Using this git URL will make triggers to ignore commit event:
Using the HTTPS git URL works:
Tags taking longer than 10s to load on an issue will timeout
Loading tags in Jira is a very resource-intensive operation and usually occurs on integrations with repositories with large git history – which can take a very long time to process/load.
Currently, the GIt Integration for Jira Cloud app limits loading of tags to 10 seconds before timing out.
Left Git Integration options panel takes up to 10 seconds to load
The left sidebar for the Git Integration for Jira app panel takes up to 10 seconds to load.
Atlassian has opened a public bug ticket for this issue.
Duplicate SC commands #comment and #time with both BBB and Atlassian SC enabled
In Jira Cloud, there are two possible Smart Commit processors: Jira Cloud and BigBrassBand.
In the Git Integration for Jira Cloud: General settings, there are two options for processing Smart commits:
- Atlassian – which supports
- GitKraken – which supports
If both are enabled, the user will see duplicate
We set the default to the Atlassian smart commit processor to enabled because it is bundled with the workflow triggers (a valuable feature). In addition, the Atlassian processor does most of the SC features plus the workflow triggers.
If the admin decides to use the BigBrassBand processing, users will be able to use the additional smart commit commands (
#label). However, choosing this path drops support for workflow triggers.