Connect GitHub to Voroa and deploy on every push
Connect your GitHub account to Voroa, choose which repositories it can read, deploy from them, ship on every push, and disconnect again whenever you want.
Connecting GitHub lets Voroa do two things for you: read a repository so it can clone and build it, and hear about a push so it can start a deploy without you asking. You grant access per repository, so Voroa only ever sees the projects you pick.
Connect your account
- From your dashboard, select Connect GitHub. The button also appears in the create-service flow, next to the repository field.
- GitHub shows you an authorize screen, confirming it is Voroa asking. Select Authorize. This tells GitHub who you are; it does not grant access to any repository on its own.
- GitHub then asks where to install Voroa. Choose your personal account or an organisation you can install apps on.
- Choose All repositories or Only select repositories, and pick the ones you want to deploy.
- Approve the install. GitHub returns you to Voroa, and your repositories are now available in the repository picker when you create a service.
The two screens do different jobs: the first identifies you, the second grants repository access. If you have already installed Voroa on GitHub, you only see the first one, and you land straight back in Voroa with your repositories ready.
You only do this once per account or organisation. Adding a repository later does not mean reconnecting — see change which repositories Voroa can see.
Organisation repositories
An installation on an organisation connects to the Voroa account of the person who performed the install, and to no other account. Being a member of the organisation is not enough on its own: Voroa cannot tell, from your membership alone, whether the organisation meant to give you its repositories, so it does not guess.
Two things follow, and both matter before you install:
- Install it yourself, from the account you want it to land in. If a colleague installs Voroa on the organisation, the repositories appear in their Voroa account, not yours.
- Start the install from inside Voroa. Use Manage GitHub access next to the repository field, and let that screen take you to GitHub. An install begun on GitHub’s own settings page arrives without anything that identifies your Voroa account, so it cannot be connected.
If Voroa is already installed on the organisation and its repositories still do not appear, remove Voroa from the organisation on GitHub first (organisation Settings, then GitHub Apps), then install it again from inside Voroa. One exception, and it matters: if a colleague already deploys that organisation’s repositories on Voroa, removing the app stops their deployments. In that case Voroa tells you so instead, and the answer is for them to add you to their Voroa workspace, where those services already are. While it is already installed, GitHub opens a settings screen instead of a fresh install, and that screen tells Voroa nothing new.
Voroa tells you when this has happened: next to the repository field it names the organisation and says what to do. Once you have connected GitHub to your Voroa account even once, a later install you start yourself connects on its own, wherever you start it.
If GitHub shows Voroa as installed but Voroa does not
Select Connect GitHub once more. Voroa re-reads which installations your GitHub account can reach and links them, so the two sides line up again without you uninstalling anything.
For an organisation this re-read does not connect the install — Voroa will not hand one member the whole organisation on the strength of their membership. See Organisation repositories above for what to do instead.
What access Voroa gets
Voroa reads only the repositories you select. It clones them to build your service, and it is notified when you push to them so it can deploy. Repositories you do not select stay invisible to Voroa, and your code stays private.
Voroa reads your code; it does not change it. It never pushes commits, opens pull requests, or edits your branches.
How a push becomes a deploy
Each service is configured with one repository and one branch. When you push to that branch, GitHub notifies Voroa, and Voroa builds that exact commit and rolls it out. Pushes to any other branch are ignored.
This runs automatically only when auto-deploy is on for the service. It is a per-service setting under Settings → Automatic deploys, so you can have one service ship on every push while another waits for you to deploy by hand. See how to enable auto-deploy for the full flow.
With auto-deploy off, your connection still works — you deploy when you choose, using Manual Deploy, and Voroa builds the latest commit on the service’s branch.
Change which repositories Voroa can see
Repository access lives in GitHub, not in Voroa, so you can change it at any time without touching your services:
- In GitHub, open Settings → Applications → Installed GitHub Apps. For an organisation, use the organisation’s settings instead.
- Find Voroa and select Configure.
- Add or remove repositories, then save.
From inside Voroa you can also select Manage GitHub access next to the repository field, wherever you choose a repository, which takes you to the same GitHub screen.
Removing a repository from the list stops Voroa from deploying it. A service that was already deployed keeps running and serving traffic — it simply will not build again until access is restored.
Disconnect GitHub
There are two ways to disconnect, depending on whether you also want to remove Voroa’s access on GitHub’s side.
Disconnect in Voroa. Open Account settings → Git deployment credentials, select the menu next to the GitHub account or organisation, and choose Disconnect. Voroa asks you to confirm first. From then on, for every service that uses that connection, in any workspace:
- pushes no longer trigger a deploy, and pull-request previews stop;
- deploys you start from the dashboard are refused with a message saying the connection was disconnected;
- the services keep running on the version they last deployed, and rolling back to an earlier deploy still works. Nothing is deleted.
The app stays installed on GitHub, so you can undo this at any time with Reconnect on the same page. Only the person who connected an account can disconnect or reconnect it.
Uninstall on GitHub. This removes Voroa’s access on GitHub’s side as well:
- In GitHub, open Settings → Applications → Installed GitHub Apps.
- Find Voroa and select Uninstall.
Voroa stops receiving pushes from that account straight away. The connection then shows as Removed on GitHub in Account settings. To start deploying again, reconnect with Connect GitHub and select your repositories once more.
Other Git providers
GitLab and Bitbucket are not supported yet. Today, deploying from a repository means GitHub. Connecting GitLab is being built - that page describes how it will work.
What is not supported
Git submodules are not fetched. This applies to every provider on Voroa: the build clones your repository alone, so a project whose build depends on submodule contents will fail to find them. Vendor the code, publish it as a package, or fetch it in a build step instead.