Skip to content

deploy.md

Latest commit

 

History

History
112 lines (82 loc) · 5.56 KB

deploy.md

File metadata and controls

112 lines (82 loc) · 5.56 KB
Raw

Deploying

The site is published by GitHub Pages, built by GitHub Actions on every push to main. There is no server to log into and nothing to rsync: git push is the deploy.

.github/workflows/deploy.yml runs npm ci, npm run build (which validates the content first), npm run linkcheck, and publishes _site/. If validation or the link check fails, nothing is published and the previous version stays live.

Publishing a change

git add -A && git commit -m "…" && git push

Then watch it land: the Actions tab, or gh run watch. A build takes about a minute.

One-time setup

  1. The repository must be named techniontdk.github.io. GitHub Pages serves a repo of that name at the domain root; any other name is served under /tdk-website/, and every link and asset on this site is root-relative (/css/site.css, /assets/…), so a subpath would load the site unstyled with every link broken. Rename it under Settings → General → Repository name, then point the local clone at the new URL:

    git remote set-url origin https://github.com/TechnionTDK/techniontdk.github.io.git

  2. The repository must be public. Pages is not available on private repositories under the free plan. That costs nothing here: everything in content/ is published on the site anyway, and no credential has ever been committed — deploy.env was gitignored from the first commit and is now gone entirely. Keep it that way: nothing secret belongs in this repo.

  3. Settings → Pages → Source: GitHub Actions. Not "Deploy from a branch" — a *.github.io repo defaults to serving its root through Jekyll, which would publish the README as the home page instead of _site/.

  4. Push to main. The site appears at https://techniontdk.github.io/.

The real address

The lab's address is tdk.cs.technion.ac.il. CS IT (Konstantin) set the DNS record on 2026-09-17:

tdk.cs.technion.ac.il.  CNAME  techniontdk.github.io.

The matching half is on GitHub: Settings → Pages → Custom domain → tdk.cs.technion.ac.il → Save, then Enforce HTTPS once the certificate is issued. Both were done the same day, and the site has served under its own name since. Until the domain is set there, GitHub answers the hostname with a 404 and a *.github.io certificate, because it does not yet know which repo owns the name — that, not a missing certificate, is what a 404 on a fresh domain means.

Enforce HTTPS is what makes http:// a 301 to https://. Expect stale answers for up to an hour after either change: GitHub's CDN caches the pre-domain 404 and the old redirect target per edge, so one region can 404 while another is already correct, and there is no purge control on Pages. It ages out on its own; re-adding the domain would only restart certificate issuance.

Publishing here is a custom Actions workflow, so GitHub commits no CNAME file and does not need one — the domain lives in the Pages settings alone. Nothing in content/ or src/ changes: url: in content/site.yaml is already https://tdk.cs.technion.ac.il, and every path is root-relative, so the site is served identically under either name. techniontdk.github.io keeps working and redirects to the custom domain.

The certificate

GitHub Pages obtains and renews a Let's Encrypt certificate for the custom domain itself, at no cost and with no action from us. No certificate has to be bought or installed — not from Harica, not from anyone; there is no server of ours to install one on.

The one thing that could have blocked it is the CAA record on technion.ac.il, which limits who may issue for the zone. It lists letsencrypt.org alongside harica.gr, sectigo.com and digicert.com, so GitHub's issuance is permitted:

dig +short technion.ac.il CAA

Issuance usually takes minutes; GitHub allows up to 24 hours before Enforce HTTPS becomes tickable. Leave it unticked until then — ticking is what stops HTTP being served at all.

Security

Pages serves static files over HTTPS from GitHub's CDN. There is no server of ours, no PHP, no database, no admin login and no upload directory — the WordPress category of compromise does not apply, and the only way to change the site is a push to main. So: protect the GitHub account (2FA), and that is the whole attack surface.

The trade: Pages sets its own headers, so the site cannot carry a Content-Security-Policy. It costs nothing today — the build emits no inline script or style, no forms, no iframes, and loads nothing from an external host. Keep it that way, per the project's own rule, and there is nothing for a CSP to defend.

When something is wrong

The build failed. The Actions log names the file. Almost always npm run validate — a slug that resolves to nothing, an unknown field, a missing image. Reproduce it locally with npm run build && npm run linkcheck; it is the same command.

The push succeeded but the site is unchanged. Check Settings → Pages says GitHub Actions, not a branch. Otherwise it is the CDN cache — hard-reload (Cmd/Ctrl+Shift+R).

The site is unstyled and every link 404s. The repo is not named techniontdk.github.io, so it is being served from /tdk-website/. See step 1.

Custom domain shows a certificate error, or 404s. The domain is not set under Settings → Pages → Custom domain, or the certificate has not been issued yet. Set it, then wait — minutes usually, up to 24 hours before Enforce HTTPS can be ticked. Check the DNS side with dig +short tdk.cs.technion.ac.il CNAME, which must answer techniontdk.github.io.