integrations

It installs where your code already lives

Four forges and two trackers, in any combination. This page is the whole surface: what each connection reads, what it writes, and what it is not permitted to touch.

4

Forges supported

2

Trackers supported

1

Repository to start

Read

Default access level

the connection record

Read, write, and never

Pick a connection to see exactly what it touches. The third column is the one worth reading, because it is the list that does not change no matter how you configure the rest.

githubForge and tracker

The most common setup. One GitHub App covers both the repository and the issues, so a single install connects the whole loop.

Reads

  • Repository contents at the commit being worked on
  • Issue title, body, labels and comments
  • Existing pull requests, to avoid duplicating work in flight
  • Check runs and workflow results, to know whether CI went green

Writes

  • A branch, named to your convention
  • Commits on that branch only
  • One pull request, with the reasoning trace in the description
  • Review comments on pull requests, when PR review is enabled

Never touches

  • Commits to your default branch
  • Force pushes, on any branch
  • Changes to repository settings, secrets or workflows
Authentication
GitHub App installation, scoped per repository
What starts a run
Webhook on issue labelled, or polling if webhooks are blocked

what connecting involves

Three steps, and you can stop after two

Nothing here requires a migration, a platform team or a change to how your repository is configured.

01

Install on one repository

Not the whole organisation. Pick a repository with a real backlog and install there. Read only until you decide otherwise.

02

Point it at a project

Choose the tracker project and the label that should open a run. Anything without that label is ignored entirely.

03

Grant write when you are ready

Write access is what lets it push a branch and open a pull request. Until you grant it, runs finish with a diff you read rather than a branch you merge.

Step three is optional and reversible. Teams evaluating EnsureFix often stay on read only for the first week and merge nothing, which is a legitimate way to run it. See what a run does.

the permission model

Three rules that hold across every connection

Configuration differs by vendor. These do not.

  1. 01

    Scoped, never organisation wide

    Every token and every app install is limited to repositories and projects you nominate by name. There is no setting that widens it implicitly.

  2. 02

    Your default branch is out of reach

    EnsureFix commits to branches it created and nothing else. It cannot force push, and it cannot merge its own pull request.

  3. 03

    Read until you say otherwise

    Write access is a separate, explicit grant. Revoking it leaves the pipeline running and simply stops it pushing.

questions

What teams ask before connecting

The five that come up in almost every evaluation.

Yes, and it is the common case. Bitbucket with Jira, GitHub with Jira, and GitLab with its own issues are all normal setups. EnsureFix treats the forge and the tracker as separate connections, so any combination in the table above works.

connect one repository

Try it against your own stack

Bring the forge and tracker you actually use. If the combination is unusual, that is the interesting demo.