Git-Native Continuous Deployment

Summary

Keep a static site’s source in a git repository and let a continuous integration runner, triggered by every push to the default branch, build the site and publish the resulting files to a static host, with the whole arrangement defined as code in the repository itself. This pattern is for HASS research software engineers and researcher-coders who already build a site as static files (see the sibling architectural pattern on statically generated sites) and want that build published automatically on every change. It reports how the RSE-CEP project does this and why that suited a project whose output is itself communicative.

Recommendation	Why?
Run the build and publish from CI on every push to the default branch, with the workflow committed to the repository.	Deployment becomes reproducible and traceable to a commit, with no manual upload and no server to run or patch. The cost is assumed git and CI literacy, a real barrier for non-coders that is better planned for than wished away.
Choose the host for what the project is for, not by habit. RSE-CEP is communicative, so it publishes to a public, highly visible platform rather than to the team’s usual self-hosted runner.	Discoverability is key when the output is the message. The accepted cost is the platform’s known relationship between workflow complexity and reliability, which RSE-CEP bounds by keeping its workflow deliberately small.

Context

This pattern suits small teams who want zero-touch publishing: edit content, open a pull request, merge, and the live site updates on its own. It pairs directly with the statically generated site pattern, which is what makes the published artefact safe to throw away and rebuild, and it is the pattern that puts the cluster’s build-time validation to work, since the validation runs in the same CI that deploys. The publish target is a concrete prerequisite: a static host the git host can deploy to.

Two of the fit conditions carry real weight. The same automation that removes the server also assumes someone who can read and maintain a workflow file, and that capability gap is better named at the outset than discovered later. And the choice of platform runs into policy: workshop participants noted that systems like GitHub are heavily used but often conflict with university IT security policy, so a user whose IT forbids the public platform needs a self-hosted or institutionally sanctioned host, which is a different context and, in time, its own pattern.

RSE-CEP’s own situation sits squarely in the matching context: a small team, a static site built by a single command, and a deliberate choice to publish somewhere public because the project exists to be found and read.

Usage

Make the default branch the source of truth. Hold the site’s content, templates, and build configuration in the repository, and treat whatever sits on the default branch as what the public site should reflect.

Trigger the workflow on push to the default branch, and add a manual dispatch trigger so a deployment can be re-run without an empty commit. Run the build inside CI: check out the repository, install dependencies, and run the build command to a static output directory. The build step is “run the static build, whatever it is”; the choice of generator belongs to the cluster’s other patterns, not here.

Use the same CI run as the gate. Because the runner already has the content and the toolchain in hand, it is where the cluster’s design pattern on schema-validated structured content (D-001) and its process pattern on build-time validation (P-001) actually execute: the content is validated against its schema, and a failure stops the deploy before anything reaches the public site. This is the sense in which continuous deployment drives those features rather than merely sitting downstream of them.

Publish the built artefact rather than committing it to a branch, so build output stays out of version history. Review before you publish: build pull requests as previews and protect the default branch, so only reviewed, merged content reaches production.

Keep the host swappable. Isolate the few host-specific steps, namely the deploy step and its environment, so that moving to another host is a contained edit rather than a rewrite. Treat a custom domain as host configuration set at the host, not as logic in the build.

Implementations

RSE-CEP is the attested implementation. The pattern site keeps its source in a public git repository, runs continuous integration on every push to the default branch, builds the site with Astro, and publishes the result to CloudFlare Pages via the Wrangler utility. A pull request builds a preview and runs the content checks; a merge to the default branch builds and publishes. The schema validation described in D-001 and the build-time gate described in P-001 both run inside that same CI step, which is what makes the deploy safe to leave unattended.

The host choice is the key decision worth attesting. The ANU team’s default for internal work is a self-hosted GitLab runner, which keeps both source and hosting inside institutional infrastructure. RSE-CEP went the other way and chose GitHub specifically because the project is communicative in nature: its value depends on being discoverable, and GitHub is a prominent, heavily trafficked platform where the work is more likely to be found. The accepted tradeoff is reliability. Independent empirical research mapping 260,000 workflows across 49,000 repositories finds that reliability and maintenance burden rise with workflow complexity, on the back of earlier studies reporting frequent execution failures. RSE-CEP accepts that risk in exchange for visibility, and mitigates GitHub’s limitations by keeping the workflow minimal: one build, one publish action. Hosting is in any case a switchable concern; the deploy step is isolated precisely so the host can change without disturbing the rest.

Similarly GitHub Pagesis a reasonable web host choice, and certainly the simplest for most projects. The ANU team uses CloudFlare primarily because it’s a preferred vendor for web hosting activities, and because the analytics features are useful for assessing the impact of an ARDC co-funded project.

This pattern is heavily attested in the wider software industry, where git-native continuous deployment to a static host is unremarkable practice. The workflow itself lives in the rse-cep-web repository under .github/workflows/.

References

Models

The artifact-based GitHub Pages deployment flow is documented in Using custom workflows with GitHub Pages. Further information on the commercial CloudFlare pages alternative to GitHub Pages.

Other resources

On the reliability tradeoff accepted above, see Aref Talebzadeh Bardsiri, Alexandre Decan, and Tom Mens, On the GitHub Actions Language: Usage, Evolution, and Workflow Reliability, 2026, which quantitatively analyses 260,000 workflows across 49,000 repositories and links higher workflow complexity to higher failure rates and greater maintenance effort.

Acknowledgments

This pattern reflects concerns raised by participants in the HASS and Indigenous RDC Community Data Lab co-design workshop, in particular that widely used platforms such as GitHub can conflict with institutional IT security policy, and that infrastructure upkeep is a barrier to entry for researchers who are not software engineers.