GitHub Copilot for Jira

Works for everything pretty well... except for what we actually wanted. Code moves pretty quickly and documentation always falls behind- even with agents doing their best. When there is a nuanced question from a customer we want to enable our service agents to be able to ask "Does the code do this nuanced thing?" and have copilot do a scan and give a sensible answer. This means we want it in Jira Service Management, which it doesn't seem to support.

GitHub Copilot for Jira — Not viable for GitLab-based organisations (I know, this is like a "duhhh" moment but something to be aware for organizations using GHC as their "agentic broker"). Getting the app installed required requesting and obtaining admin access to GitHub Copilot within my organization, which added friction to the process. Once approved, activation was completed successfully - but with many hiccups. Moreover, the app doesn't let me block the type of subscription you can utilize to access GHC via Jira - in other words, an employee with a personal GHC subscription can log in to their account, instead it should allow the admin to set the organizational URL so that the user can only log in using their corporate account. However, the core limitation quickly became apparent: the Jira-native agent assignment flow requires that the deployed agent operates on repositories hosted on GitHub. For organisations using GitLab as their primary source control platform, this integration path is entirely blocked. This is a significant constraint that is not prominently communicated upfront (only in during the install of the app). Teams evaluating this app should be aware that it is effectively GitHub-exclusive when deployed via the Jira-first approach (which makes sense from a business perspective). Until GitLab is supported as a repository source, this app cannot be recommended for GitLab-based environments.

• 

  GitHub

  Hi Ray, thanks for your review. The integration is designed to work with GitHub-hosted repositories. If you'd like to discuss the specifics of your situation, please complete this short survey and leave your email so we can follow up. Thanks.

Look personally I am not impressed. I can understand if our org has multiple repos, the agent does need to be told which repo from the org it needs to work on, however it should be able to also pull that from title or description context. And then there is the branch issue. If I need it to work on the dev branch instead of main/master/release, it will not do it. it seems to always start from the main/master/release branch. It also does not seem to reliably use the already in progress branch with the issue key as prefix (e.g. PROJ-123-Some-Feature). I'm sure it will improve but right now it is not adding value. Lastly, there seem to be two copilots... one that when finishing work has the tag Github Copilot for Jira, and one that is simply Github Copilot. You get messaged by the former when a PR is ready, but need to tag the latter to start new work. It's all rather clunky.

• 

  GitHub

  Hi Xavier, thanks for reaching out.
  I'm curious if you have used the customisation options available at the space-level? If not, I recommend trying this for specifying repo name. The customisation can also be used for branch naming that you wish to apply to any ticket. Please also feel free to share your details here and I'm happy to follow up with you directly to reduce friction.
  If you would like to be kept in the loop re Atlassian's work on the 'two different Copilots', please submit a support ticket here. Thank you.

Took a bit of back and forth between our GitHub and Atlassian team, but the Product team at GitHub were fantastic, got us set up and are keeping us informed with roadmap items as they land. Thanks for the ongoing support ❤️

• 

  GitHub

  Thanks so much for your review, Jamie.
  Pleasure working with you, and you know where to find us. Happy coding!