Source: https://joinfinn.com/integrations/github

# GitHub

## GitHub + Finn.

GitHub integration with Finn. GitHub hosts software repositories, code reviews, issues, and development automation.

Business function: Engineering and data.

## What you can do with GitHub.

GitHub hosts software repositories, code reviews, issues, and development automation.

### Take a bug from report to release

Finn investigates a reported defect, makes the code change, and carries the fix through testing, review, and release.

**Typically handled by:** Software engineer and quality assurance engineer

**Starts when:** A reproducible bug reaches the repository issue queue.

#### What Finn handles

1. Read the issue, reproduce the failure in a development environment, and identify the responsible code.
2. Create a focused branch with the fix and a regression test, then run the repository's checks.
3. Open the pull request with evidence, address review feedback, and merge when required reviews pass.
4. Follow the authorized release workflow, verify the corrected behavior, and close the issue with the release reference.

**The result:** The issue links to the tested change and the release that fixes it.

### Deliver a scoped product improvement

Finn turns an agreed feature request into working code, tests, and release documentation while keeping the product owner informed.

**Typically handled by:** Product engineer

**Starts when:** The product owner accepts a feature's scope and acceptance criteria.

#### What Finn handles

1. Read the specification and existing implementation, then record the development tasks on the issue.
2. Implement the feature on a branch and test the user journey against the acceptance criteria.
3. Submit the pull request, resolve review comments, and update documentation alongside the code.
4. Merge after required approval and track the release workflow through the feature's verification.

**The result:** The agreed feature ships with its implementation, tests, documentation, and issue history connected.

### Repair a broken build

Finn investigates a failed GitHub Actions run and fixes the cause so the team can continue shipping.

**Typically handled by:** Build engineer

**Starts when:** A required workflow fails on a pull request or the main branch.

#### What Finn handles

1. Read the failed job's logs and compare the change with the last successful run.
2. Reproduce the failure and correct the code, test, or workflow responsible on a branch.
3. Run the affected checks and submit the repair for the repository's required review.
4. After merge, confirm the previously failing workflow succeeds and update the blocked issues or pull requests.

**The result:** The failed build has a verified repair, with the successful run linked to the change.

### Finish a dependency security update

Finn follows a vulnerable dependency from the alert through a tested update and the resulting security status.

**Typically handled by:** Application security engineer and maintenance developer

**Starts when:** Dependabot reports a vulnerability affecting a repository dependency.

#### What Finn handles

1. Read the advisory and dependency path to identify the affected package and available fixed version.
2. Review the dependency update or create the change, then test compatibility and the affected application behavior.
3. Request the required security or code review and merge the accepted change.
4. Track release completion and recheck the dependency alert, reporting any unresolved exposure separately.

**The result:** The repository records the update, its tests, release status, and the alert's current disposition.

### Run the release checklist

Finn gathers completed changes, checks readiness, and completes the release records and communications around the team's deployment process.

**Typically handled by:** Release manager

**Starts when:** The team sets a release version and deployment window.

#### What Finn handles

1. Collect the merged changes and open release blockers, then confirm the required checks and approvals.
2. Write release notes that explain the delivered behavior and include migration or operator instructions where needed.
3. Create the release and invoke the designated deployment workflow after its production approval.
4. Read the deployment result, check the release verification, and send the finished release notes to the connected Slack channel.

**The result:** The release has an accurate change list, deployment result, and stakeholder announcement.

### Close the loop on a customer defect

Finn connects a support case to the engineering fix and tells the customer when the corrected behavior is available.

**Typically handled by:** Support engineer

**Starts when:** A Zendesk case identifies a product defect that needs a code change.

#### What Finn handles

1. Collect the customer's reproduction details and link the case to a GitHub issue without copying unnecessary customer data.
2. Reproduce and repair the defect, add the test, and carry the pull request through review.
3. Follow the release that contains the fix and verify the customer's reported behavior.
4. Use connected Zendesk to send the resolution and update the case, linking the shipped fix and any remaining customer steps.

**The result:** The customer receives the fix information and both support and engineering records show the resolution.

### Keep documentation current with the code

Finn updates the instructions that a software change affects and publishes them through the repository's normal review and delivery process.

**Typically handled by:** Technical writer and developer relations engineer

**Starts when:** A merged feature or API change makes existing documentation inaccurate.

#### What Finn handles

1. Compare the delivered behavior with the repository's user guides, examples, and release notes.
2. Rewrite affected instructions and examples, then run documentation checks and the example's relevant test.
3. Submit the documentation pull request and resolve the owner's review comments.
4. Merge the update, follow the documentation publishing workflow, and link the published instructions to the feature issue.

**The result:** Readers can find instructions that match the released behavior, with the publishing result recorded.

### Resolve review feedback

Finn works through actionable pull request comments, makes the requested changes, and returns a tested update to the reviewer.

**Typically handled by:** Software engineer

**Starts when:** A reviewer requests changes on a Finn-owned pull request.

#### What Finn handles

1. Read each unresolved review thread and distinguish requested code changes from questions or product decisions.
2. Make the agreed changes on the pull request branch and update tests or documentation affected by them.
3. Run the required checks and reply to the review threads with the change and verification evidence.
4. Request another review and merge only after the repository's approval requirements are satisfied.

**The result:** The pull request contains the reviewed changes and an explicit answer to each actionable comment.

### Remove a recurring maintenance chore

Finn implements an agreed repository maintenance task so repeated manual work becomes part of the team's existing automation.

**Typically handled by:** Developer productivity engineer

**Starts when:** The team asks to automate a specific recurring repository chore.

#### What Finn handles

1. Inspect how the chore is done today and identify the existing script or GitHub Actions workflow that owns it.
2. Implement the bounded automation with the inputs and permissions the task needs.
3. Test the workflow in the development path and submit the change for maintainer review.
4. Merge the accepted update, observe its first intended run, and document the completed result for the team.

**The result:** The named maintenance job runs through repository automation with a documented owner and outcome.

### Investigate a release regression

Finn connects a production regression to recent repository changes, carries out the authorized response, and follows through on the permanent fix.

**Typically handled by:** On-call developer

**Starts when:** Datadog or PagerDuty links a new production problem to a recent release.

#### What Finn handles

1. Read the incident evidence, release changes, and workflow results to identify the likely regression.
2. Use the incident's authorized rollback workflow when needed and confirm recovery through connected Datadog.
3. Reproduce the defect in development, implement the repair, and submit tests with the pull request.
4. After review and release approval, verify the correction and update the incident and repository issue.

**The result:** The incident records service recovery and the tested permanent correction, with each release result linked.

## Connection setup

Contact Finn to discuss the records your workflow needs and the actions you want it to perform.

Your team chooses what Finn can access, what agents can change, and when a person must approve the work. The connection needs the appropriate account access and permissions from GitHub.

## Explore Finn

- [Agents](https://joinfinn.com/agents): Help customers. Work with your team. Finish the job.
- [Systems](https://joinfinn.com/systems): Business apps for the work behind the conversation.
- [AI Gateway](https://joinfinn.com/ai-gateway): Control connected AI apps, models, access, and spending.

[All integrations](https://joinfinn.com/integrations)

[Discuss this integration](https://joinfinn.com/contact)

[Discuss your workflow](https://joinfinn.com/contact) · [How it works](https://joinfinn.com/demo/app/#/w/borough/overview) · [Get started](https://joinfinn.com/app/#/signup)