Docs
Support

GitHub

Connecting Eido Build to your repositories on GitHub with a GitHub App your organisation owns.

Eido Build works on your GitHub repositories through a GitHub App named Eido, which your organisation creates and owns. There is no token to paste or renew, and GitHub never needs to reach your Eido Build.

Connect GitHub#

You need to be an owner of the GitHub organisation, or have one to hand.

  1. Go to Admin → Integrations and open GitHub.
  2. Press Create the app on GitHub. Eido Build describes the app to GitHub.
  3. On GitHub, an organisation owner confirms the new app.
  4. GitHub then asks which repositories to install it on. Choose the repositories Eido Build may work on.

You are sent back to Eido Build, and the GitHub panel now lists which projects’ repositories the app can reach.

How Eido Build uses it#

Whenever Eido Build needs a repository, it asks GitHub for a token for that one repository that lasts an hour.

  • A stage that writes code gets a token that can push to that repository.
  • An agent with read-only code access gets a token with read permission only, so GitHub itself refuses a push.
  • No token is ever given to an agent. Inside the sandbox, Eido Build adds the token to git’s requests on the agent’s behalf.

Adding a repository later#

To let Eido Build work on another repository, add it to the app’s installation on GitHub: Organisation settings → GitHub Apps → Eido → Configure. Then point a project at it in Projects.

The GitHub panel in Eido Build tells you when a project’s repository is not one the app can reach.

Repository settings to check#

Automatically delete head branches should be off if any workflow merges more than once, for example into uat and then into main. GitHub deletes the branch at the first merge, which leaves the second with nothing to merge. Eido Build deletes the branch itself after the last merge. See Branches, builds and pull requests.

Branch protection applies to Eido Build as it does to everybody. A pull request Eido Build opens still needs the approvals your rules require, from people.

Builds#

The Build view on a work item reads GitHub Actions for the work item’s branch. There is nothing to set up for it beyond the app.

Popular

Your first work itemRaise an enhancement and follow it through triage, the agent stages, approval and the merge.User guideHow a workflow runsThe stages a work item passes through, who has each one, and what each status means.User guideAcceptance criteria and QAWriting down what done means, testing a change against it with evidence, and deciding what happens to the bugs that turn up.User guideCutting a releaseFreezing a release, running its checks, deciding what to do about what they find, and shipping it.User guideOdieThe assistant on every page. It reads everything you can read, and anything it wants to change becomes a card for you to press.User guideCosts and budgetsWhat agents cost, where to see it, and the caps that stop a stage, an agent or a month from overspending.AdministrationIntegrations for agentsLetting agents act in other systems by granting them specific actions, without ever handing them a credential.AdministrationLicensingHow Eido Build checks its licence, what it sends when it does, and what to do if it locks.Install and licence