Control which Repo is associated with Jira Project(s)

[dennisroche]

👋

I couldn't find an answer to this in previous issues or the documentation.

Following GitHub recommendations, we have 1 main GitHub org for many teams/repos (500-1000+).

We have at least 3x Jira Sites (that I know of). Can we link multiple Jira Sites to the same GitHub org? Or do we need to pick only one?

[mboudreau]

You can have as many different Jira instances as you want for the Github app :tada:

The only requirement is that you have Admin permissions on the Github org and Manage Apps permissions on your Jira site. Just install the Github app on the jira side and add an organization to it. It should list your organization and you can connect it to your Jira instance if you have the admin rights. If the org isn't showing, it's because you need to install the Github app on your organization first.

Let me know how you go and feel free to close the issue if everything works. Cheers.

[dennisroche]

@mboudreau thanks for reply - i'm happy to close the issue.

[dennisroche]

@mboudreau, reopening this issue as related question.

As we have many teams in the same GitHub organization, is there a way to associate a repo/s with the Jira Project?

e.g. [TES-] with org/repo-1, org/repo-2 etc.

This association could prevent accidental linking/closure of Jira issues from unrelated repos.

It could be achieved using https://github.com/probot/probot-config in .github/jira.yaml file in each repo.

[mboudreau]

That's a great question, but unfortunately it's not possible at this time to filter the repos per Jira instance. Currently it's done at the GitHub organization level, so either the GitHub app can see every repo or only a select few. However, this isn't affected the same way when connecting it to the Jira side.

There has been some talks about configurations like this to prevent ticket ID collisions between instances, but for the moment there needs to be some level of mindfulness of ticket IDs across instances.

That being said, another way we've seen this done is to split up your GitHub organizations into smaller orgs and install the app into each separate one. It's not pretty and definitely adds some maintenance overhead, but it is a solution that works right now.

It's good to hear of some the more complex situations and structure as it'll help us decide the direction of the app for the enterprise users. Let us know if there's any other situations that we can improve upon.

Cheers.

[dennisroche]

That being said, another way we've seen this done is to split up your GitHub organizations into smaller orgs and install the app into each separate one. It's not pretty and definitely adds some maintenance overhead, but it is a solution that works right now.

We want to avoid that as against the advice from GitHub as it can inhibit collaboration, creating unnessary silos between teams (not to mention the management overhead).

That's a great question, but unfortunately it's not possible at this time to filter the repos per Jira instance.

Sorry, let me rephrase the question. At the GitHub organisation level, we want to enable all repos however want to then associate/assign repos to a Jira project so that another team can't accidentally close unrelated issues.

e.g. we have 2 Jira projects:

• ASDF
• HAC

Only the pull requests for the repos linked to ASDF are allowed to close ASDF issues, i.e. it is similar to limiting scope/authorization what GitHub events can trigger.

[mboudreau]

Ah, right.

Can you walk us through how you think this situation would happen where a ticket from one project is used in a different repo which then closes the ticket?

[dennisroche]

I'll admit it is low-risk/occurance as typically the ticket is copy/pasted from Jira to the PR.

But possible situation could when it is manually entered, e.g. typos. As we have 100s of projects across multiple Jira sites, there is likely many similar project keys.

Now that I've had to explain it, it's a minor concern that could be mitagated by other controls and at worse-case the ticket can always be reopened.

[mboudreau]

It's minor, but still something to consider as I don't think there's a way to "disassociate" a typo-ed commit/PR/branch from a ticket and is kinda annoying as per lack of control. I wanted to address this at some point, but need ammunition to bring forward to the business that we should work on more granular control :)

[dennisroche]

It's minor, but still something to consider

It is actually a deal breaker and lack of this control will block us from deploying to our enterprise. We had the same issue with the GitLab integration.

Options:

1. Link/associate repos using settings as mentioned above
2. Step down the permissions required for the integration to work

[mboudreau]

It is actually a deal breaker and lack of this control will block us from deploying to our enterprise. We had the same issue with the GitLab integration.

I mean, the alternative is that you don't have the integration at all and instead waste a lot of your developers' time doing everything manually instead of the potential occasional fixing of a closed ticket that wasn't meant to be done.

Just to clarify, you're saying there will never be a situation where a ticket or epic is multi-repo? If the problem is that tickets are automatically closed, you could always not have the automation to close it when the PR is merged and let your developers do it manually. I've personally experienced it when a ticket had to be done across a few repos and the ticket kept getting closed/reopened because of all the different PRs.

I'll have to talk further with my team as there might be a way of doing this with jira automation. If not, we'll have to investigate further to see if there's a simple way of accomplishing this.

[dennisroche]

I mean, the alternative is that you don't have the integration at all and instead waste a lot of your developers' time doing everything manually instead of the potential occasional fixing of a closed ticket that wasn't meant to be done.

Yes, unfortunately. The accidental closure/tagging of commits/branches etc might confuse or cause alarm for our non-technical people that also use Jira.

Just to clarify, you're saying there will never be a situation where a ticket or epic is multi-repo? If the problem is that tickets are automatically closed...

Can we turn off auto-close or map it differently? As merging a PR isn't the end of the delivery process, it's a step that needs to be tracked against the Jira story.

I'll have to talk further with my team as there might be a way of doing this with jira automation. If not, we'll have to investigate further to see if there's a simple way of accomplishing this.

Appreciate the effort into investigating this.

[thombergs]

Hey @dennisroche,

Can we turn off auto-close or map it differently?

Auto-closing can be triggered by "smart commits" (https://support.atlassian.com/jira-software-cloud/docs/process-issues-with-smart-commits/), i.e. a developer uses a key word in the commit message to trigger a Jira key transition. To disable this, developers must stop using those key words. I don't think there's a way to disable this other than stopping to use the key words, currently.

Or, you might have configured the auto-closing with Jira automation rules (https://www.atlassian.com/software/jira/features/automation), which is the more elegant and maintainable solution. In this case, developers don't need to use a key word in the commit message, but instead you define a rule that auto-closes a Jira issue when a pull request is merged, for example. If you have done this, you would have to disable the automation rule that auto-closes Jira issues.

Does this help?

[dennisroche]

Hi @thombergs 👋.

Does this help?

No, unfortunately as this change alone won't prevent a typo-ed smart commit from associating data with an incorrect Jira project 😕.

I understand that the Jira App currently requires administrator permissions to run, giving it access to all projects. Would it be possible to drop the permissions down after installation? e.g. it can only update Jira project A,B,C, and not D. That would allow us to exclude the "sensitive" projects in our Jira sites from being updated by unauthorized users (via GitHub).

[dennisroche]

"sensitive" projects in our Jira sites from being updated by unauthorized users (via GitHub)

☝ the actual reason why this is an issue for our enterprise owner and our non-technical users.

[thombergs]

Hey @dennisroche,

understood. It seems the best solution to help you here is to have a feature in the GitHub integration that allows you to configure which repositories may send data to which Jira projects, like you mentioned in the first comments.

We'll discuss this feature request in the team.

[rachellerathbone]

Hey @dennisroche would git commit message hooks solve the problem you're having?

[dennisroche]

@rachellerathbone thanks for looking at this.

would git commit message hooks solve the problem you're having?

unfortuantely no ☹️.

git commit hooks are optional as each user needs to install/configure the hooks when they clone the repos. Also, hooks can be bypassed by a user using the --no-verify flag.

[brsolomon-deloitte]

This limitation is impacting us as well and preventing us from integrating GitHub with Jira.

Our organization uses a GitHub Enterprise (Cloud) Organization that is home to many disparate Teams, with each having their team's private repositories there, siloed off from other Teams. Similar to OP's description, Teams commonly have separate Jira Cloud Software accounts also. It seems like granting access to repositories is effectively "all or nothing" which does not work due to privacy requirements. If Team A owns repos 1, 2, and 3, while Team B owns repos 4, 5, and 6, then Team A's Jira should only recognize/integrate/have visibility into repos 1, 2, and 3, while Team B's Jira should only recognize/integrate/have visibility into repos 4, 5, and 6.

[ccrolf]

Interesting @dennisroche, I thought GitHub (Enterprise) supported pre/post receive hooks (TIL)

One work-around could be to add a GH action that runs a bash script checking that the commit messages contains the issue key regex for the specific Jira projects you want to limit association to.

[rachellerathbone]

Hey @dennisroche. Just wanted to check in and see if the above suggestion helped with your issue or if you need further assistance?

[dennisroche]

Interesting @dennisroche, I thought GitHub (Enterprise) supported pre/post receive hooks (TIL)

@ccrolf - GitHub Enterprise Server has support for pre-recieve hooks. There are a few different versions of GH Enterprise - we're using GitHub Enterprise Cloud (i.e. github.com).

One work-around could be to add a GH action that runs a bash script checking that the commit messages contains the issue key regex for the specific Jira projects you want to limit association to.

As GitHub Actions is event based and checks run in parallel, there is no way to prevent the Jira App from commenting or tagging the incorrect project.

if the above suggestion helped with your issue or if you need further assistance?

@rachellerathbone, sorry 😞. This is issue still needs further assistance.

[Jetaldesai]

This is critical feature for any enterprise and I am surprise that despite of having this configuration as default feature, we have to open discussion.

[dennisroche]

@mboudreau @rachellerathbone it has been a few months and wanted to check-in if this still on your radar/backlog? It still has the label awaiting response so it might be filtered from your boards.

[rachellerathbone]

Hey @dennisroche. Apologies, we forgot to update the label. We have created a ticket in our backlog but, unfortunately, I can't tell you at this point when it will be picked up by one of the devs on our team;.

[ca-takuno]

Hello. @rachellerathbone

Is there any update of information about this issue?

We too have many repositories in one github organization and would like to map our repositories to the Jira project. The reason is to limit the access scope.

We are very much looking forward to this feature.