We often have epic stories which span multiple repositories. I am looking for a mechanism to track all the work that is associated with a single story. GitHub has Issues which is a close to the solution I seek. The problem with Issues is they do not span multiple repositories. On deployment day I still need to scan ~10 repositories (there are 100 repo's, 10 are commonly used) to discover which ones have commits related to the story.
As a manual workaround I create multiple Issues. One Issue for each repository. Then I manually list the Issue#'s related to the epic story in Jira.
Is there a tool or alternative technique I can use to automatically combine these issues and treat them as one?
It would be a bit unusual to use both JIRA and GitHub Issues together. JIRA offers virtually everything that GitHub Issues does and more.
This guide from GitHub shows how you can integrate JIRA directly with GitHub, skipping Issues altogether. When properly configured you will see links to GitHub in mentioned JIRA issues. You can also trigger JIRA workflow changes based on keywords in your commit messages, much like GitHub Issues does out of the box.
Related
Context
I often found valuable projects with many forks. Sometimes I would like to add something to the original functionality, so I go for forking. However to prevent reinventing the wheel, I would like to ensure no one done such kind of work before. So I review the existing forks, but usually those just a stalling copies. In case of 100 forks this is a tedious work.
Question
Given a github repo, how to see if one or more of its fork has measurable activity? I would like to do this to filter out the "just another copy" like forks.
GitHub has a network graph as one of their features for Understanding connections between repositories. This provides a:
Timeline of the most recent commits to this repository and its network ordered by most recently pushed to.
This would show the most recently active forks just below the main repository. You can access it at https://github.com/<user>/<repo>/network, e.g. here's one from one of my repos.
I don't think Github itself provides an easy way to do this, but some third-party tools have been written to help with that.
gitpop3 for example supports sorting the forks of a given repository by either number of stars, forks, commits or the last modified date.
Are there best-practice guidelines for maintaining a GitHub repository? I've contributed to many open source projects and used GitHub for projects that I work on solo, but now I'm working with a team of six developers, including myself, to build a system, and I've been placed in charge of maintaining the repository. Nothing is to get merged into our main branch without my approval. As little as I know about maintaining a GitHub repository, of those within the organization (two team members are consultants) I've the most experience with the process.
But I've never maintained a GitHub repository, and while I'm doing OK, I know that there must be a body of knowledge out there of how to handle this correctly. I just haven't been able to find it.
One hurdle I've been jumping over repeatedly, for example, is merge conflicts. Usually they're minor, but not always. Is there some known system available that allows me to enforce who has the ability to edit which files at any given time, for example?
And yes, I realize this may not be the best Stack Exchange forum, but none of the others seemed more suited to the topic.
The Cloud Native Computing Foundation (CNCF) serves as the vendor-neutral home for many of the fastest-growing open source projects, including Kubernetes, Prometheus, and Envoy.
As such, it can be used as a starting point for your own project: see contribute.cncf.io/maintainers/github/, which offers:
template, to be usre you have your README, LICENSE and other important files.
labels, to better classify your issues
Add also a clear "release and maintenance policy", and you should be in good shape.
Github provides nice feature to manage feature completeness OR sprint completeness. It's called Milestones and it's really nice.
However, sometimes we need to track both completeness of the feature (e.g. "Refactoring payment systems integration") and completeness of the sprint (e.g. "Sprint week 15").
Is there any way to do so using Github issues?
GitHub does not currently allow you to assign multiple milestones to an issue. There is an issue tracking this feature request, but there seems to be little movement on it.
There's a couple of workarounds possible. The simplest one is to use Milestones to track sprints, and labels to track features. While labels do not give you the nice "X% completed" overview that Milestones do, you can quickly (single click) get an overview of all issues tagged with a label, and see how many are open vs. closed.
Another possibility is that you use Task Lists (see GitHub Markdown guide) to your advantage. Instead of having each issue belonging to a particular feature as an independent GitHub issue, you track the entire feature as a single issue, and add a Task List to the issue to track individual items. The advantage of this is that you get a nice progress bar in your issue overview, showing you feature completeness. A disadvantage is that you cannot assign individual tasks to separate developers any longer.
It is possible integrate github with a custom application that track issues? This custom issue tracker is developed by people that is not involved with github development, but can code some plugin or feature that provides a pattern to refer a external issue.
The pattern can be #I or something like this.
Thoughts?
As far as I'm aware, most popular enterprise solutions are building integrations with GitHub repositories via webhooks (if they don't already offer them). If this is a in-house custom solution you will have to build that integration yourself.
You'll need to register a webhook for each repository and you will have to know how to associate events from different repositories with different issues.
With the webhook set-up you'll be able to inspect pull requests, pushes to different branches, etc. and you can use whatever syntax you want to refer to issue ids in your issue tracker. If your repository is also public facing and has issues (and pull requests) turned on, you will definitely not want to overlap usage of #numerical_id with your own issue tracker. In that case, you will want to choose something like ^ or & or % which isn't currently claimed by anyone else. What you choose for that, though, is entirely up to you.
Im using Jira with Bitbucket, and I wonder - can I somehow store info about that one or more revisions are related to some ticket, without writing ugly prefixes like ABC-123 in commit-messages?
The only other solution is to login to JIRA UI and create an issue link to the commit page in Bitbucket.
Obviously, this is somewhat more work than just adding ABC-123 in the commit.
Short answer: not really
The problem is that most version control systems don't allow you to store extra structured data related to a commit. The least common denominator is the commit message, so it tends to get used for all kinds of logically separate data, e.g. JIRA issue keys, change the status directions etc. The git notes feature might be used for this.