Skip to content

Reuse One Release ID in Every Local Verification Example#110

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ptr727 merged 2 commits into from
Aug 24, 2026
Merged

Reuse One Release ID in Every Local Verification Example #110

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ab5807d
Reuse one release id in every local verification example
ptr727 Aug 24, 2026
5abc2e1
Fail closed in every release snippet's git rev-parse
ptr727 Aug 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 10 additions & 5 deletions OPERATIONS.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -76,17 +76,21 @@ So release to the local mirror and run the live check **before** opening a pull
| `hugo.yaml`, `layouts/` | Permalink and taxonomy changes move URLs underneath the redirects that point at them. |

```sh
set -e
set -a; . ~/.secrets/Blog.local.production.env; set +a
ENV_FILE=~/.secrets/Blog.local.production.env deploy/make-release.sh
checks/check-live-urls.sh "$SITE_BASE_URL"
RELEASE="$(git rev-parse --short HEAD)"
ENV_FILE=~/.secrets/Blog.local.production.env deploy/make-release.sh "" "$RELEASE"
EXPECT_RELEASE="$RELEASE" checks/check-live-urls.sh "$SITE_BASE_URL"
Comment thread
coderabbitai[bot] marked this conversation as resolved.
```

Name the file in both places, even when it is the default, since `make-release.sh` sources `ENV_FILE` independently of the shell above and a value already exported earlier in the same session would otherwise win silently over the sourced one:
Name the file in both places, even when it is the default, since `make-release.sh` sources `ENV_FILE` independently of the shell above and a value already exported earlier in the same session would otherwise win silently over the sourced one. The empty first argument leaves the deploy root at the sourced `DEPLOY_ROOT`, and `RELEASE` is reused so `EXPECT_RELEASE` verifies the release the command just built rather than skipping the release-stamp guard. `set -e` matters here too: a failed `git rev-parse` would otherwise leave `RELEASE` empty, which silently skips the check's own release-stamp verification instead of failing loud:

```sh
set -e
set -a; . ~/.secrets/Blog.local.staging.env; set +a
ENV_FILE=~/.secrets/Blog.local.staging.env deploy/make-release.sh
checks/check-live-urls.sh "$SITE_BASE_URL"
RELEASE="$(git rev-parse --short HEAD)"
ENV_FILE=~/.secrets/Blog.local.staging.env deploy/make-release.sh "" "$RELEASE"
EXPECT_RELEASE="$RELEASE" checks/check-live-urls.sh "$SITE_BASE_URL"
```

**There is no restart step, and that depends on one flag.** The container runs `caddy run --watch`, which re-adapts the config on a timer and reloads it in process. Re-adapting re-executes every `import`, so a new release's `Caddyfile` and `maps/*.map` are picked up through the unchanged `/config/Caddyfile` that the watcher actually names. Measured on this host: content is live the instant the symlink moves, and the rules follow within about a quarter of a second.
Expand DownExpand Up@@ -142,6 +146,7 @@ Three properties of how the credential is handled, each there for a reason worth
## Deploying

```sh
set -e
RELEASE="$(git rev-parse --short HEAD)"
SITE_BASE_URL=<base-url> deploy/make-release.sh <deploy-root> "$RELEASE"
EXPECT_RELEASE="$RELEASE" checks/check-live-urls.sh <base-url>
Expand Down
6 changes: 4 additions & 2 deletions README.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -178,9 +178,11 @@ checks/check-url-parity.py public
Build a release and verify it against a running server:

```sh
set -e
set -a; . ~/.secrets/Blog.local.production.env; set +a
ENV_FILE=~/.secrets/Blog.local.production.env deploy/make-release.sh
checks/check-live-urls.sh "$SITE_BASE_URL"
RELEASE="$(git rev-parse --short HEAD)"
ENV_FILE=~/.secrets/Blog.local.production.env deploy/make-release.sh "" "$RELEASE"
EXPECT_RELEASE="$RELEASE" checks/check-live-urls.sh "$SITE_BASE_URL"
```

The deploy root and the base URL come from a file per environment in `~/.secrets/`, named `Blog.<server>.<environment>.env`, copied from [example.env][env-example] and selected with `ENV_FILE`. `~/.secrets/Blog.local.production.env` is the one read when `ENV_FILE` is unset. The real files live on the host, never in this checkout.
Expand Down
6 changes: 4 additions & 2 deletions deploy/README.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -53,9 +53,11 @@ neither. Seven facts are the whole contract:
## Building a release

```sh
set -e
set -a; . ~/.secrets/Blog.local.production.env; set +a
ENV_FILE=~/.secrets/Blog.local.production.env deploy/make-release.sh
checks/check-live-urls.sh "$SITE_BASE_URL"
RELEASE="$(git rev-parse --short HEAD)"
ENV_FILE=~/.secrets/Blog.local.production.env deploy/make-release.sh "" "$RELEASE"
EXPECT_RELEASE="$RELEASE" checks/check-live-urls.sh "$SITE_BASE_URL"
```

The deploy root and the base URL are the only host-specific values, and they pair per
Expand Down