GitHub Community
Allow issues to belong to a project and be "linked" to multiple repositories #6433
Replies: 68 comments 12 replies
Yeah it's a bummer that even the new version still does not provide this very simple yet crucial functionality. For now I'll be using one repository as the single place to create issues across all the repos and will be using Github issues Beta for its boards/views. |
|
@hugonteifeh how do you reference your issues from the project commits without it taking too much of the commit space? |
|
Very true. It is a little disappointing that this feature is still missing. I don't want to use the third-party tool for project management since it makes sense to have the issues, tickets, and everything else that has to do with code live with the repositories in GitHub. But missing this important feature, I have to use something else for now. |
Ideally it would also allow the 'Break issues into actionable tasks' capability to break a task list out into issues for multiple repos while keeping the parent feature at the project level and maintaining the tracking tree. |
|
Yeah this is what is pushing me to linear |
|
This is possible to do now with the "Tasklist" feature. It is currently in beta, but I got access only a day after applying. You should check it out, it looks really promising. What you can do is create an issue in one repo and the create a tasklist in that issue with issues in other repos. You can also track progress based on the status of the linked issues. |
I'm curious, did u switch to it at the end? How did it go? |
|
Very good idea. I would add, it would be great that each project could have it's own setting. For example, I have 2 projects that I want to always reference issues in my "Issues" project. But these 2 projects still have pull requests, so the PR # would conflict with the issue numbers in my "Issues" project. My suggestion:
Also, my 2 repos already have issues feature disabled, possibly only allow this when issues is disabled. |
|
I'm surprised by low number of comments on this feedback. Maybe almost everyone is one another project/issue trackers and only use Github Issues for bugs/feature requests. |
|
Even if the fields supported markdown like in the actual GitHub tickets, you can link to another repo with a shorter custom text, would be better than nothing! |
|
This is really a huge bummer to use Github issues. Currently it's just a simple issue tracker, but no project management tool, where you can break down things and define epics, stories and tasks. Already just a simple story/task separation would be great. |
|
Call it "project management tool" is literally a blasphemy. It's full of limitations and the one mentioned here is just a piece of the puzzle:
Evaluating to switch to Linear as well. |
|
I think this feature request is receiving less love because for people to ask for a "feature" they are usually already able to use your software. This limitation of github issues is so crippling that many of us can't even think about using github issues before it's implemented. |
|
Upvote on this for sure! We are currently having to duplicate an issue across 2 to 3 repos to make sure we track it in our various apps that are affected by a change or a bug fix. Of course, that is a lot of extra work and we may miss a detail in a spec or feedback. @github-staff Please please. Give this request some lovin. |
|
Project-level issue could be an alternative to project-level/cross-repo PR as suggested in #13733. |
|
It seems they are so close to having this feature. With the new project capability, they have the concept of 'draft' issues which exist only in the project (not in a repo). All they need to do is add the task-list feature to this (like they have for repo issues) - oh, and not call them draft! |
|
They really need to focus into this! :( |
|
Second time I try to get into github projects, but how do teams actually use this to get anything organized? Simple repo scenario: API and frontend, not a mono-repo. Now how am I supposed to create and organize a simple password-reset flow that requires actions and stories within two repos in parallel to get this shipped? I open up a repo-unbound project. I add draft tasks. From this point on I'm forced to use repo bound things: Issues, milestones, PRs and so on.
it just does not feel like anything useful. Either a project has to be equal to an epic, or this is just a huge manual copy/paste scratchboard with no real influence on anything. Actually abusing projects as epic feels like the way it is intended, but somehow it also feels just wrong. |
|
It's crazy how this fundamental features still being lacking cripples GitHub Projects as being viable for any project or organisation that doesn't have a single monorepo. We're still stuck with JIRA because of this, but I'm curious if anyone has found any decent work arounds outside of just using third party tools instead? |
|
Hey @Samreay, I ended up with a less-than-ideal solution:
This made it quite inconvenient for us to link commits to issues (because of the long notation which can easily have typos) so we ended up deciding to use "squash merge" from PRs which has worked pretty well and kept the commits on the This solution has its drawbacks though and it'd be much better if a native solution was provided by GitHub of course, but maybe you can give it a go and see if it works for you. |
|
You're right, really don't understand why this is especially in a world of micro-services where each service typically has its own repository. |
|
Indeed, I really wish GitHub would provide an answer to this. It's annoying every day especially when dealing with Epics haha. |
|
Upvoting this feature request. |
|
+1 |
|
+1 |
|
Please let's get this done, it would help us a lot since we're doing all our product management in GitHub Projects. |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 Came here looking to link three repos together in different meta-repos to one project board...and was left sad |
|
Does anybody know if this is even in the roadmap? |
|
Its very difficult to work with the way it is and easy for the issue to end up in the wrong repo that projects randomly chose that I had access to. I was ready to drive all new teams into the projects if it was not for this very large feature gap that is making me reevaluate going to a different solution. |
|
I would be interested too! |
|
Sad this is still an Issue today, and Microsoft keeps pushing Azure Boards agenda into my employer to handle some basic stuffs, but can't auto link an board task with the issue making me create both, and manual link them. What decadence has become GitHub, let's see if they will push again the idea of billing the self hosted runners. |
|
Thanks for sharing this idea. We also face the same problem in our project. We use many repositories for different apps and some common internal libraries. This helps us reuse code, but it becomes difficult when we want to track issues. Most of the time, one issue is related to more than one repository, but GitHub allows an issue to belong to only one repository. Because of this, we sometimes have to create multiple issues for the same problem, which is confusing. If GitHub allows creating issues at the project level and linking them with commits from multiple repositories, it would be very helpful. It would make issue tracking easier and save time for teams like ours. Hope this feature can be added in future updates. |
|
Is this ever going to happen? It would make our processes so much easier and so much confusion would be avoided! |
|
I am able to link PRs from different repositories within the same project using gh graphql CLI commands at the moment. #!/bin/bash
#############################################
# Link a Pull Request to an Issue (Cross-Repo)
#############################################
# CONFIGURE THESE VARIABLES
PR_OWNER="" # GitHub organization/owner name
PR_REPO="" # Repository containing the PR/branch
PR_NUMBER=""
ISSUE_OWNER="" # GitHub organization/owner name
ISSUE_REPO="" # Repository containing the issue to link the PR to
ISSUE_NUMBER=""
# Closing keyword (Fixes, Closes, Resolves, or "Relates to" for non-closing link)
KEYWORD="Fixes"
#############################################
# Script Logic (No changes needed below)
#############################################
echo "📎 Linking PR #${PR_NUMBER} (${PR_OWNER}/${PR_REPO}) to Issue #${ISSUE_NUMBER} (${ISSUE_OWNER}/${ISSUE_REPO})..."
# Get PR node ID and current body
RESPONSE=$(gh api graphql -f query="
query {
repository(owner: \"${PR_OWNER}\", name: \"${PR_REPO}\") {
pullRequest(number: ${PR_NUMBER}) {
id
body
}
}
}")
PR_ID=$(echo "$RESPONSE" | jq -r '.data.repository.pullRequest.id')
CURRENT_BODY=$(echo "$RESPONSE" | jq -r '.data.repository.pullRequest.body')
# Build issue reference
if [ "$PR_OWNER" = "$ISSUE_OWNER" ]; then
ISSUE_REF="${ISSUE_OWNER}/${ISSUE_REPO}#${ISSUE_NUMBER}"
else
ISSUE_REF="https://github.com/${ISSUE_OWNER}/${ISSUE_REPO}/issues/${ISSUE_NUMBER}"
fi
# Append link to body
NEW_BODY="${CURRENT_BODY}
${KEYWORD} ${ISSUE_REF}"
# Update PR using Python to handle JSON escaping properly
python3 << PYEOF
import json
import subprocess
payload = {
"query": "mutation(\$prId: ID!, \$body: String!) { updatePullRequest(input: {pullRequestId: \$prId, body: \$body}) { pullRequest { url } } }",
"variables": {
"prId": "${PR_ID}",
"body": $(echo "$NEW_BODY" | jq -Rs .)
}
}
result = subprocess.run(
["gh", "api", "graphql", "--input", "-"],
input=json.dumps(payload),
capture_output=True,
text=True
)
if result.returncode == 0:
print("✅ Successfully linked PR to issue!")
print(f" PR: https://github.com/${PR_OWNER}/${PR_REPO}/pull/${PR_NUMBER}")
print(f" Issue: https://github.com/${ISSUE_OWNER}/${ISSUE_REPO}/issues/${ISSUE_NUMBER}")
else:
print("❌ Error:", result.stderr)
exit(1)
PYEOF``` |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
In our organisation, we have multiple internal library repositories that are used from multiple app repositories. This allows us to share a lot of code and not have to write it multiple times, but it brings a problem when trying to deal with issues in Github as they belong to one repository only. Because of this limitation, we decided to move to another issue tracker that allows us to create an issue that can be referenced from the commits of multiple repositories.
It'd be great if this feature can be added to the new version of Github Projects/Issues as it'd allow teams like ours to create a single issue that belongs to the project and can be easily "linked" in the commits of multiple repositories :)
All reactions