How To Link GitHub Issues to GitHub Releases

We’re a fan of GitHub Issues. This built-in feature offers a great way to track bugs and work items in a GitHub repository. It helps developers focus on their tasks and keep their plans current without using third-party software.

But our team faced a challenge when we switched from Azure DevOps to GitHub [ LINK TO “Switching from Azure DevOps to Github” POST ]: The platform doesn’t offer a direct way to link GitHub Issues to GitHub Releases. It doesn’t have an out-of-the-box feature to track which issues are closed in a specific release automatically.

You may wonder, why do we want to link Issues to Releases?

We wanted to track our progress for each release and add issues to the version we’re preparing for launch. Linking Issues to Release will show which backlog items are included and closed in each product release.

We can roll out our software confidently when we know all the issues in a specific version are resolved.

We built a system to address this challenge and make GitHub Issues and Releases work better for the team. Here’s what we did.

How To Link GitHub Issues To GitHub Releases

We use GitHub Milestones, which allow teams to track progress on a group of issues or pull requests, to create our workaround.

Here are the 7 steps to link closed issues to a release via a milestone:

1. Create an issue and set the correct area label(s) (e.g., bug, maintenance.) If you don’t want the results to be part of the public release notes, assign the “internal” label.
2. Set a milestone to match the version (e.g.,  5.xxx.) In the release note, a default milestone could look like “{major_version}.xxx” (e.g., xxxfor Azure DevOps Extension Timetracker.)
3. Write a closing comment to accompany the release note. It should sum up how the issue was resolved.
4. Perform a new release and create a new milestone associated with the release version (e.g., 34.0)
5. Have all closed issues from the major version (e.g., 5.xxx) automatically reassigned to the milestone associated with the new version, which will be marked as “closed” when you complete the release.
6. Use GitHub API to get the list of release issues with release note comments as a markdown table.
7. Turn the markdown table to a public release notes article.

Make GitHub Work Better For Your Team

While GitHub Issues may not be a 1:1 replacement for Azure DevOps or other enterprise systems out of the box, it’s flexible and extendable in many ways. Plus, it’s unbeatable for running open-source projects and building a community to support your product.

The example here is just one way you can make GitHub work better for your team.

Here at 7pace, we understand the importance of tracking your time and managing your project where you work (e.g., on GitHub) so you don’t have to juggle more tools or transfer information from one software to another.

That’s why we created 7pace for GitHub to help you make the platform work better for your team. Developers can track their time and have it automatically associated with each work item or issue. You can also pull real-time reports to assess progress and get insights to inform your planning process.

Sign up for 7pace to see how effortless it can be to track your time on GitHub and make better estimations.