Test builds on GitHub Pages

Guidance last updated: 9 November 2026

The Pages workflow publishes master at /en/latest/ and each live test branch at /en/<branch>/. A test branch name must start with test_ and contain only letters, numbers, dots, underscores or hyphens after that prefix. For example, test_newsletter is published at https://docs.hpc.shef.ac.uk/en/test_newsletter/.

Prepare and review a test build

  1. Ensure the test-build workflow has merged into master. Create the test branch from the updated master so it contains the workflow file.

  2. Merge the draft content branch into the test branch and push it to the repository. Check the Pages workflow run and open the direct preview URL. Append the page’s normal path to inspect a particular page.

  3. Push later changes to the test branch as needed. Each push to master or a test_* branch rebuilds the main site and all current test branches, so the preview remains available through ordinary deployments.

  4. After review, merge the content branch into master through the usual pull request. Once the live page is correct, delete the remote test branch. Its deletion triggers a deployment without that preview.

The workflow’s manual run option can rebuild the site if a run fails. A failed branch build stops deployment, leaving the previous Pages site in place until a successful run replaces it. Check the workflow result after deleting a branch to confirm its preview has actually gone.

Preview URLs are publicly accessible even though the source repository is private. The robots.txt rule discourages indexing of /en/test_ paths; it does not control access. Do not put confidential material in a test branch.