Skip to content

Deployment: private repo, public site, public downloads

This page describes how to host Registry Forge - Patient Edition with a private source repository, a public documentation site, and public release downloads. This is the recommended posture during early development when the source is still moving fast or when collaborators are working with PHI-adjacent test data.

The pieces

  1. Source repository at github.com/BoyceLab/RegistryForge4Patients - private
  2. Documentation site at boycelab.github.io/RegistryForge4Patients/ - public
  3. Release artifacts under the public Releases tab of the same repo - public

The trick is that GitHub Pages can serve from a private repository to a public URL, and Releases can be public even when the source isn't. You don't need a separate public mirror.

One-time setup

1. Repository visibility

In Settings → General → Danger Zone:

  • Set repository visibility to Private

2. GitHub Pages

In Settings → Pages:

  • Source: GitHub Actions (not "Deploy from a branch")
  • Visibility: Public (this option appears for private repos; it lets the published site stay public even though the source is private)

Confirm the public URL still resolves: visit https://boycelab.github.io/RegistryForge4Patients/ in an incognito window.

3. Releases

The Releases tab is governed by the repository visibility setting but release assets attached to a release can be set to public. In Settings → General → Features:

  • Enable Releases

When you publish a release (next section), the release page and its attached assets will be publicly accessible at the same URL as any other GitHub release, even though the source repo is private. The source tarball that GitHub auto-generates from a tag will require authentication to download because it contains the source; the assets you explicitly attach do not.

Publishing a release

# Tag a release commit
git tag -a v0.1.0 -m "Initial public release"
git push origin v0.1.0

Then on GitHub:

  1. Go to Releases → Draft a new release
  2. Choose tag v0.1.0
  3. Title: v0.1.0 - Initial public release
  4. Body: brief notes
  5. Attach binaries:
  6. RegistryForgePatient.zip (source bundle - the same one you produce from zip -r ... RegistryForgePatient/)
  7. registry_forge_patient_bundle.zip (demo output bundle from sample_data/)
  8. Optionally a built wheel if you want pip-installs to skip the build step
  9. Set as the latest release checked
  10. Publish release

The release page is now at https://github.com/BoyceLab/RegistryForge4Patients/releases/tag/v0.1.0. The attached assets are at predictable URLs like https://github.com/BoyceLab/RegistryForge4Patients/releases/download/v0.1.0/RegistryForgePatient.zip and are publicly accessible.

Updating the install instructions

Every place that currently says pip install git+https://github.com/BoyceLab/RegistryForge4Patients.git will break for anyone outside the BoyceLab GitHub org once the repo goes private. Replace with one of these:

Option A: install from a release asset

pip install https://github.com/BoyceLab/RegistryForge4Patients/releases/latest/download/RegistryForgePatient.zip

The release asset is public; this works for anyone. Pin to a specific version by using /download/v0.1.0/ instead of /latest/download/.

Option B: PyPI

pip install registryforge-patient

If you push to PyPI (recommended for a stable release line), this is what users do. PyPI publication is independent of GitHub repo visibility.

Option C: download-then-install

# From the public Downloads page
wget https://boycelab.github.io/RegistryForge4Patients/assets/release/RegistryForgePatient.zip
unzip RegistryForgePatient.zip
cd RegistryForgePatient
pip install .

Document Option A as the default. It's the simplest and works without any extra services.

Updating the GitHub Actions workflow

The existing .github/workflows/docs.yml will continue to build and deploy the docs from a private repo. No changes needed there. But check:

  • The workflow runner has read access to the repo (it does by default - workflows in a private repo can read that repo)
  • The actions/checkout step doesn't need credentials beyond ${{ github.token }}

Run this grep to find every place that references the install URL:

grep -rn "git+https://github.com/BoyceLab/RegistryForge4Patients" .

Likely candidates:

  • README.md
  • docs/installation.md
  • docs/quickstart.md
  • notebooks/01_quickstart.ipynb
  • notebooks/personal/maintainer_testing.ipynb (the !pip install ... cell)
  • pyproject.toml (the Repository URL stays, since auth-gated access is fine for the source URL itself)

For each, swap the git+... URL for the public release-asset URL.

Privacy considerations

Going private with the source code does NOT change the privacy story for end users:

  • The tool itself still runs entirely locally on the researcher's machine. No network calls.
  • The reasoning for keeping the source private during this phase is to limit external contributions to vetted collaborators, not to hide the code from auditors. Anyone who needs to inspect the source can request access.
  • The published documentation continues to fully describe the algorithm, the parser behavior, the disclaimers, and the limitations. Privacy of the repo doesn't mean opacity of the tool.

If you eventually want to make the source public again, the workflow above is reversible: flip visibility back to Public in Settings, and the same Pages URL keeps working without changes.