GitHub Pages Setup¶
Set up a GitHub Pages site for an OpsDev.nz module with a custom domain.
Goal¶
Publish Zensical documentation for an OpsDev.nz module through GitHub Pages
with a custom domain (e.g., op.opsdev.nz, octodns-metaname.opsdev.nz).
Prerequisites¶
- GitHub access with administrator access to the repository.
ghinstalled and authenticated.uvavailable in the OpsDev.nz repository.- OctoDNS and the Metaname test credentials available through the normal environment and 1Password workflow.
- A GitHub Actions workflow for Zensical docs deployment (see Step 3).
All commands assume the OpsDev.nz repository root and use uv run to execute
within the project venv. If the venv doesn't exist, uv run creates it
automatically.
Do not put API tokens or secret values in the repository, workflow, or DNS zone. The DNS record and GitHub Pages configuration are not substitutes for access control.
1Password prerequisite¶
Before running OctoDNS validation, plans, or applies:
- Unlock/sign in to 1Password using the normal local CLI workflow.
- Load the Metaname test account credentials through the existing
env/metaname-test.envconfiguration. - Select the OpsDev.nz resolver hook:
- Confirm that the resolver can access the test account without printing the secret values.
Use the test credentials only for the test zone configuration. Do not load production credentials while testing this change.
❯ eval $(op signin)
Enter the password for john.opsdevnz@gmail.com at my.1password.com:
❯ source env/metaname-test.env
1. Test the DNS change¶
Add a clearly temporary test name to the test zone rather than the production record. For example, after confirming the target with GitHub:
Review the entire zone diff before running OctoDNS.
Run the validation and dry-run from the repository root:
uv run octodns-validate --config-file octodns/configs/metaname.test.yaml
uv run octodns-sync --config-file octodns/configs/metaname.test.yaml
Without --doit, octodns-sync prints the proposed changes and does not apply
them. Review the plan and confirm that only the intended test CNAME is added.
When the plan is correct, apply the test change through the existing manual test
deployment process. Do not add --doit until the plan has been reviewed.
Verify propagation using a resolver that is not relying only on local cache:
The result should match the GitHub Pages target. Remove the temporary test record after the test has served its purpose, and run another OctoDNS plan to confirm the cleanup.
2. Research the custom-domain requirements¶
Read the relevant GitHub documentation:
For a subdomain, GitHub requires a CNAME record pointing at the repository
owner's Pages hostname. For the startmeup-nz organization, that is:
If the repository lives under a different owner (e.g., a personal account or another organization), confirm the target in the GitHub Pages settings before applying DNS changes.
3. Confirm the GitHub Pages workflow¶
Ensure the module has a GitHub Actions workflow for docs deployment. A typical workflow:
- Triggers on pushes to
main; - Checks out the repository;
- Installs Python and Zensical;
- Builds the
docs/site; - Uploads the
site/directory as a Pages artifact; and - Deploys it with the GitHub Pages deployment action.
Verify the workflow exists at:
Verify the build works locally from the module directory:
The build must complete without errors. Do not start zensical serve from an
automated runbook session; the human operator controls long-running servers.
4. Configure GitHub Pages for the repository¶
In the GitHub repository:
- Open Settings → Pages.
- Set the publishing source to GitHub Actions.
- Confirm the workflow has the required
pages: writeandid-token: writepermissions. - Confirm the
github-pagesenvironment is available to the repository. - Merge the workflow to
mainand wait for the Documentation workflow to complete. - Open the default project Pages URL shown by GitHub and confirm the Zensical site renders.
Do not configure the production custom domain until the test DNS process below has been completed successfully.
5. Configure the production custom domain¶
After the test passes:
- In GitHub Settings → Pages, enter the custom domain (e.g.,
octodns-metaname.opsdev.nz). - Confirm the Pages UI accepts the domain and reports the expected DNS target.
- Add the production CNAME to the zone file.
The expected shape (using octodns-metaname as an example):
- Run
uv run octodns-validateand a dry-runuv run octodns-syncagainst the production configuration. - Review the production plan carefully before applying it.
- Apply the production DNS change through the guarded manual process.
GitHub may create or require a CNAME file as part of custom-domain
configuration. Follow the Pages settings and workflow guidance rather than
creating a conflicting file by hand.
6. Verify the published site¶
After the DNS record propagates and GitHub verifies the domain, Let's Encrypt provisions an SSL certificate. This can take a few minutes to an hour.
Once the certificate is active:
- Enable Enforce HTTPS in GitHub Settings → Pages.
- Verify the site loads at
https://<custom-domain>/.
Verify all of the following:
Then check manually:
- the certificate is valid for the custom domain;
- the home page renders;
- navigation links do not point at local-only paths; and
- a new documentation change merged to
maintriggers a successful Pages deployment.
7. Rollback¶
If the DNS change is wrong:
- Stop applying further changes.
- Restore the previous zone entry in the relevant YAML file.
- Run
uv run octodns-validateand a dry-run plan. - Apply the rollback through the same guarded process.
- Check the GitHub Pages custom-domain setting and deployment status.
Do not delete the GitHub repository or Pages environment as a first response; DNS rollback is the smaller and more reversible action.