What happens after a change goes up

A change to ipe.rest reaches visitors through a short workflow on GitHub. It copies the site, checks it, publishes it and tells search engines what is new. Most runs finish in under 40 seconds.

The last entry described how the pages get built. This one starts where that ends, when a change reaches the main branch of our repository. The figures are from 10 November 2026: the workflow file, a local build of the site, and the last eight runs on GitHub.

Copy

The site is plain files, so the first step is a copy. The workflow checks out the repository and copies everything except what visitors do not need: the scripts, the tests, the workflow itself, version-control data and any Markdown files. Of the 586 files in the repository, 329 go into the site folder, about 10 MB.

Check

Then seven tests run against that folder, not against the repository. They look for the files a visitor needs, such as the robots file, the sitemap, the service worker and the home pages; for folders that must not be there, such as scripts and tests; and for the 404 page, which must be marked noindex and link home. A failure stops the workflow here. Nothing is published, and the previous version stays live.

Publish

Next the folder is uploaded and handed to GitHub Pages, which serves it. Only one deploy runs at a time: if a newer change arrives while one is running, the older run is cancelled. There is no server of ours in between and no database. When the service worker version changes, a visitor’s browser installs a fresh cache and deletes the old ones on a later visit.

Tell

After publishing, the workflow sends IndexNow, a protocol that Bing, Naver, Yandex and other search engines accept, the addresses of pages whose sitemap date is today in Korean time. The key it needs is a public text file in the site’s root. This step is allowed to fail: if it does, the deploy still counts as a success.

How it has gone

Of the last eight runs, seven succeeded and one failed; the next run, 22 seconds later, succeeded. Five of the seven successful runs took under 40 seconds, and the slowest took 2 minutes 18 seconds. We measured from the start of a run to its last update, so read the times as approximate.

What a green run does not say

A passing run says the files arrived and seven checks passed. It does not say a page looks right on a small phone screen, and IndexNow only informs search engines; it promises nothing about when, or whether, they list a page.

ipe(); // copy, check, publish, tell

The workflow is short on purpose. Fewer steps leave fewer places for a quiet site to break.