Skip to main content
Warning This document has not been updated for a while now. It may be out of date.
Last updated: 4 Oct 2021

Make a GitHub repo private

In cases of an ongoing security incident, or when working on politically sensitive changes, we may want to work in private rather than public. We do this by creating a private fork of the application.

Creating a private fork

To fork an existing GOV.UK repository and make it private perform the following steps:

  1. Visit and click the green ‘New’ button to create a new repository.
  2. Click on the ‘import repository’ link to import the existing repository.
  3. Change the owner to alphagov.
  4. Set the repository name to the new private name.
  5. Set the ‘Privacy’ setting to ‘Private’.
  6. Start the import. This may take a while to complete.
  7. Click on ‘Settings’ and then ‘Manage access’ to set the permissions on the repository.
  8. Add the team ‘GOV.UK - CI Bots’ so that Jenkins can access the repository for deployment. Make sure it is set to ‘write’ access because Jenkins needs to access the repository and set the release tag.
  9. Add the ‘gov-uk’ team and set it ‘write’ access so that developers can create and merge pull requests.
  10. Consider adding a GitHub action to replace Jenkins CI that will not be running on this new repo.
  11. Add a branch protection rule against the main branch. You can use the settings in another repo as a template.

Deploying the private repository

Update govuk-app-deployment

To deploy a private repository, first create a private fork of the govuk-app-deployment repository named govuk-app-deployment-private.

In the govuk-app-deployment-private repository there is a directory for each app in GOV.UK that can be deployed. Find the directory of the app you want to make private and edit the file <app>/config/deploy.rb to add a line to set the name of the private repository. For example, for ‘frontend’ add line 2:

set :application, "frontend"
set :repo_name, "frontend-private"

As in the ‘Creating a private fork’ section, you must add the team ‘GOV.UK - CI Bots’ as collaborators on the private repository.

Update Jenkins

Perform these actions on staging first, before rolling out to production.

In the relevant environment, disable Puppet on the Jenkins machine, otherwise Puppet will overwrite your changes. This can be done by SSHing into the Jenkins machine:

$ gds govuk connect -e <environment> ssh jenkins
$ govuk_puppet --disable

Jenkins must be updated to use the private version of govuk-app-deployment so the private version of the app is deployed. This is done by navigating to the Jenkins UI in your web browser, clicking the ‘Configure’ link and changing the ‘Build’ section:





The app can now be deployed as normal.

After deployment is complete, Puppet can be re-enabled:

$ gds govuk connect -e <environment> ssh jenkins
$ govuk_puppet --enable

Testing in private

We do not have CI builds on our private repos by default. To mitigate the risks of this, you can either:

  • Add a GitHub Action to do these things for you
  • Or, run the following manual steps locally before pushing:
bundle exec rubocop # run the linter
RAILS_ENV=production bundle exec rake assets:precompile # make sure production assets compilation works
bundle exec rake # run all the tests

Keeping repositories in sync

As part of our workflow we will need to keep our private repositories in sync with the public ones. To do this we need to open a terminal, enter the directory of the private repository we want to sync up and add an ‘upstream’ remote.

$ git remote add upstream

We can now fetch commits from the upstream public repository and pull them in a new branch which can be merged into main through the usual Pull Request workflow.

$ git fetch upstream
$ git diff upstream/main main # check if we need to rebase at all
$ git checkout -b update
$ git pull upstream main
$ git push origin update

Reverting to public

In order to make our private changes public, we need to incorporate them into the public repo.

  1. Make sure you have pulled in the latest changes from the public repo into the private repo (detailed in ‘Keeping repositories in sync’).
  2. Merge any pending pull requests into the main branch of the private repo.
  3. On the public repo, add the private repo as a new upstream remote: e.g. git remote add upstream
  4. Create a new branch on the public repo.
  5. Rebase the main branch of the private repo onto the new branch:
  6. git fetch upstream
  7. git rebase upstream/main
  8. git rebase main
  9. Raise a PR on the public repo for the new branch.
  10. Delete the private fork, once the changes have been merged into the public repo.