# GitHub for DevRev
Sync GitHub and DevRev so issue status is always real-time and driven by code.
## **Overview**

<img src="https://raw.githubusercontent.com/shashankcube/image/main/github-automation.png" align="center"/>

Connect GitHub with DevRev, and ensure your work stays in sync between the two systems, such that issues and statuses are always real-time and driven by code activity. GitHub for DevRev is a snap-in that has been used by several organizations and ties DevRev issues closely with GitHub activity, eliminating the need for humans to manage issues.

Why should you un-manage your work? You should use this snap-in if you want to reduce work about work. Let machines manage issues, including creating and updating statuses, so developers can focus on work that matters. You’ll resonate with this if you have ever:

- Delivered a hot-patch and realized you never had an issue to track it
- Wasted time just updating your team on the status of an issue
- Or just felt that creating and managing issues is a distraction

If your team’s best practice is to link your GitHub activity to an existing issue ID during branch creation, commits, and PRs, then this snap-in will honor that and enable a GitHub-driven issue state, without auto-creating issues. [Here](https://devrev.ai/docs/integrations/github#github-events) are the different ways you can link your DevRev issue to GitHub branches, commits and PRs.

However, if you choose to work in GitHub and never created or linked an issue, you shouldn’t have to sweat it. This snap-in will automatically create issues that track all associated commits, branches, and pull requests. The auto-created issue is enriched with PR description and related GitHub events. The status of these issues is driven by GitHub activity, and the issues will auto-transition stages, from In Development to In Review, and Closed. Your work is always accounted for and more importantly, your team members have visibility and know what you’ve been up to, resulting in fewer interruptions.

## **How it works**

To enable GitHub for DevRev, click on **Install** and we'll walk you through a few simple steps including connecting with GitHub. You'll have a default set of configuration settings and the option to further personalize this snap-in. Learn more about the features in this snap-in.

## **Features**
This snap-in is powerful and has several configurable features. As they say, the power is in the defaults! When you install this snap-in, we'll configure defaults that are tried and tested. You always have the option to personalize further.

**Automatic status updates**

You can associate GitHub commits, branches, and pull requests with the DevRev issue they correspond to. Doing so allows you to see GitHub activity in the corresponding DevRev issue and to act on those events, allowing you to automate away your manual tasks. Mention DevRev issues in GitHub, and route the relevant GitHub events to this issue. They can be mentioned either as display IDs (ISS-34) or object IDs (issue:34), case-insensitively. A DevRev issue can be mentioned in branch names, commit messages, or PR titles.

**Autocreate issues from GitHub branch / PRs**

To make use of this feature, go to **My settings** on the **Configuration** screen of the snap-in and toggle **Enable for me**. This setting is not applied across the entire organization, each user must enable it.
You can enable the **Create DevRev issue when a new branch is created** or **Create DevRev issue when a new PR is opened**, depending on your preferences. It would be ideal if you enabled one of them rather than both.

**Autocreate issues from GitHub branch**

If you do not explicitly associate your DevRev issue to GitHub branches, commits, or PRs, then we can auto-create your issues so you have an account of all your GitHub activity. This feature automatically creates an issue when a new branch is created, and tracks all associated commits and pull requests on this issue. The auto-created issues will move status based on Git activity, to in development based on branch and commit activity, and in review when PRs are created. When PRs are merged, the issue will be automatically closed, though this behavior is configurable.

**Autocreate issues from GitHub PRs**

You can choose to automatically create issues when a new PR is created, and it is not linked to an existing DevRev Issue. The behavior is similar to how issues are auto-created with new branches. The auto-created issues will move status based on Git activity, and events are posted on the DevRev issue timeline.

Issues auto-created from GitHub branches or PRs are called autonomous issues, and have the tag `autonomous`.

**Attribute part to autonomous work**

Autonomous issues originating from GitHub will be attributed to a default part. You can configure the default part while setting up your snap-in. Every issue in DevRev must have a part attribution.

**Enrich autonomous work descriptions**

Enrich autonomous issues with information derived from GitHub PR events. The title and description of an auto-created issue are enriched with the PR data. When a new GitHub PR is opened or edited, then the related autonomous issue description is updated with the latest PR description. If the user has removed the auto-generated text, then the automation will no longer update the description from PRs. Similarly, autonomous work titles are updated with the PR title, if the user hasn’t already updated it.

**Link autonomous work with related issue**

Create a related link between the work items mentioned in the PR body and the autonomous issues tagged with the branch/PR. When a new GitHub PR is opened/edited, for all the autonomous tagged work items(by branch/PR), automatically mark the issues mentioned in the PR as related.

**Automatically close autonomous work**

Autonomous work gets closed when its related PR is merged. However, if there is no PR activity on this work, then the autonomous work is closed after a configurable period.

**GitHub Commands**

Enable quick actions to close or attribute a PR to DevRev issue(s) with the slash command.

* `/towards` - Use the `/towards`  command in the PR description to associate the related GitHub activity to the issue(s). This will ensure that the PR and issue are linked such that related events are posted and issue status is driven by GitHub events.

* `/close {work-id}` - Use `/close ISS-3 ISS-4` in a PR body to automatically close a specific issue(s) when the PR is merged. You can also use `/close #work` to close all associated issues with a PR when that PR is merged without knowing the specific IDs.

**Automatic PR tasks**

When a pull request is requested or reopened, a DevRev task is created for you. For this automation to be triggered, you'll need to link your Pull Requests to DevRev issues. If your PR is removed, merged, or closed, then the Task gets deleted. However, if you submit your PR review, then the task is closed.

**Automatic PR reminders**

When a pull request is inactive for more than a specified number of days, then this automation will post a message in all related DevRev issues. You'll need to link your GitHub Pull Request to the DevRev issue to enable these reminders. There are several ways to link your GitHub Pull Requests to DevRev Issues. You can do so by mentioning the DevRev issue ID in the pull requests title or body, or mentioning it in the branch name or commit message. Reminders are also posted for issues created autonomously.

You can choose to set up the inactive period in the number of days through the max_inactive_days setting.

**Automatic programming language skill identification for dev users**

When a pull request is merged, the automation identifies the programming languages used in the PR and adds them as skills to the Dev user who submitted the request. To enable this feature, reach out to the DevRev customer experience team.

**Installation**

For detailed installation and configuration instructions, refer to the [Github documentation](https://docs.devrev.ai/integrations/github).


github.svg

DevRev Marketplace

GitHub

Your issues on Autopilot. Sync GitHub and DevRev so issue and status is always real time and driven by code.