If working closely with Github, starts with reading Github: Building a CI server as an adequate primer.

A simple continuous integration server using Hookbot to subscribe to branch changes on Github hosted repositories.

Assumptions:

• The CI server has access to write files (git clones) to its current working directory on start time.
• Repository branch changes are published to a topic on a Hookbot server instance the CI server can subscribe to.
• Repositories are cloned using the git-prep-directory command instead of git clone.
• .seaeye.yml configuration file in the root of the repository

TBD.

When using Docker-out-of-Docker (DooD) and volume mounts are required but the paths inside and outside can't be made equal, the volume path inside must be a prefix to the outside path and the special environment variable SEAYEYE_WORKSPACE must be set. E.g.:

 -v /seaeye/workspace=/seaeye/workspace # OK
 :
 -e SEAEYE_WORKSPACE=/seaeye/workspace -v /data/seaeye/workspace=/seaeye/workspace # OK
 :
 -e SEAEYE_WORKSPACE=/seaeye/workspace -v /data/seaeye/workspace=/seaeye # NOT OK

Any interaction with Github initiated by Seaeye is authenticated and authorized against a Github user. This allows pulling from repositories and updating commit statuses. Don't add the machine user as collaborator but as a member to the new team.

1. Generate a new SSH key
2. Create a new Github Team (e.g. bots)
3. Create a new Github Machine user (e.g. seaeye)
4. Add the new organization member to the new team

Note: Adding a machine user as a collaborator always grants read/write access while adding a machine user to a team grants the permissions of the team.

Note: Automating the creation of accounts is prohibited by Github's ToS:

Accounts registered by "bots" or other automated methods are not permitted.

Note: Most private Github repositories have Git submodules linked to other private Github repositories, so using Github's Deploy keys would require a more complex setup (configuring Seaeye's access rights on the server side instead of on Github administration side, which will require e.g. CloudFormation changes) or reusing the same key. It also leaves the task of pushing commit statuses open.

• Github: Building a CI server
• Github: Managing deploy keys