Welcome to JIRA-GitHub Auditor, an innovative solution designed to streamline and secure the pull request review process by seamlessly integrating GitHub and JIRA. This project addresses the need for Project Managers to review GitHub pull requests directly from the JIRA interface, eliminating the necessity for granting unnecessary GitHub access.
Key Features
Effortless Integration:
Connect JIRA issues with corresponding GitHub pull requests effortlessly, creating a unified workflow.
Secure Review Process:
Enable Project Managers to review pull requests within the familiar JIRA environment, minimizing exposure to unnecessary GitHub access.
Audit Trail Transparency:
Maintain a robust and verifiable audit trail, ensuring compliance with audit requirements and providing a clear history of reviews and approvals.
Permission Control:
Keep GitHub access limited to developers, enhancing security and ensuring that only essential team members have direct code access.
Custom Approval Process:
Design and implement a customized approval process within JIRA, allowing for seamless collaboration and clear communication among team members.
Problem Statement
Streamline pull request approval for project managers while ensuring auditability and eliminating the need for unnecessary GitHub licenses.
Solution
Developed a workflow that integrates GitHub pull requests with a custom Jira issue type for approval tracking. This solution leverages automation and webhooks to:
Create Jira issues automatically upon pull request creation in GitHub.
Allow project managers to approve pull requests within Jira without granting them GitHub access.
Post approval comments directly on the pull request in GitHub.
Benefits & Impact
Enhanced Security: Mitigate the risk associated with unnecessary GitHub access for non-developer roles.
Improved Collaboration: Foster collaboration between development and project management teams with a unified review process.
Configurations
GitHub
Create a GitHub Repository webhook, Specify the webhook URL to point to the Jira automation endpoint that captures PR details and subscribe to the Pull request event that occurs on GitHub.
Issue types distinguish different types of work in unique ways, and help you identify, categorize, and report on your team’s work across your Jira site. They can help your team build more structure into your working process.
Description: Approvals represents the GitHub Pull Request approval. This issue type will be for Project Managers/Approvers who are managing the GitHub Project outside of GitHub. An external approval taken from JIRA.
a. Fields:
Description fields: These fields describe the work that needs to be done. They display prominently in most views.
Summary [Required]: This is a mandatory field that provides a concise and clear overview of the issue. Ideally, it should be 255 characters or less for optimal readability. Think of it as a headline that captures the essence of the problem or task.
Description: This optional field allows for a more detailed explanation of the issue. Describe the symptoms, steps to reproduce, expected behavior, and any other relevant information that helps understand the problem and how to resolve it.
b. Context Fields:
These fields provide context to the work, and help group, filter, and report on similar issues.
Assignee: This field indicates the person responsible for working on the issue. Selecting an assignee improves accountability and helps track progress.
Labels: These user-defined keywords categorize issues for better organization and filtering. Use them to group related issues or indicate priority levels.
Parent: This field links the current issue to another related issue, often called a "subtask" or a "dependent issue." It helps clarify hierarchical relationships and dependencies.
Pull_Request_Number [Required]: This custom field stores the unique identifier of the associated pull request in GitHub.
c. Reporter:
This field shows the user who initially created the issue. It provides an audit trail and helps identify who raised the concern. This field is hidden when its empty.
2. Custom issue field:
In the above issue type, we have a context issue, 'Pull_Request_Number'. This is a custom issue type created to extract the pull request number from GitHub.
Here, I am using it to extract the PR number data from GitHub using Webhook data.
Trigger: GitHub Incoming webhook Pull_request event. This rule is triggerd whenever a Pull request activity occurs in GitHub.
Action 1: As soon as the rule is triggered, a log action is captured to display the Pull_request activities. For instance, Pull request assigned, auto merge disabled, auto merge enabled, closed, converted to draft, demilestoned, dequeued, edited, enqueued, labeled, locked, milestoned, opened, ready for review, reopened, review request removed, review requested, synchronized, unassigned, unlabeled, or unlocked.
IF condition: We set a condition to proceed further, only if the Pull_request activity is "opened".
Action 2: This action will 'Create an issue', whenever PR is opened:
Project: Specify the project name.
Issue type: Approvals
Choose a field to set: Assignee, Description
Summary* [required]:
Pull Request#{{webhookData.number}} for {{webhookData.repository.name}}
The above expression will create an issue in JIRA with a title that includes information about a specific GitHub pull request. The placeholders like {{webhookData.number}} and {{webhookData.repository.name}} will be dynamically replaced with actual data from the webhook payload when the automation rule is executed.
Description:
{{webhookData.pull_request.user.login}} has created Pull Request
#{{webhookData.number}} for {{webhookData.repository.name}}.
Link to Pull request {{webhookData.pull_request.html_url}}
{{webhookData.pull_request.body}}
The above snippet retrieves information regarding the GitHub PR :
Username: {{webhookData.pull_request.user.login}} indicates the GitHub username of the user who created the pull request.
Pull request number: {{webhookData.number}}, represents the pull request number.
Repository name: {{webhookData.repository.name}}, specifies the name of the repository where the pull request was created.
Link to Pull request: {{webhookData.pull_request.html_url}}, provides a direct link to the pull request on GitHub.
Pull request description: {{webhookData.pull_request.body}}, displays the description of the pull request.