From a837c04212971cd630109bf437cb0d9dc37dac7a Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Wed, 28 Oct 2026 14:27:04 -0700 Subject: [PATCH 1/2] Name the Values make-release.sh Reads From Its Env File The example template and two OPERATIONS.md sentences still credited the shell's sourced DEPLOY_ROOT, or every value in the file, to the script. Co-Authored-By: Claude Opus 5.5 --- .secrets/example.env | 2 +- OPERATIONS.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.secrets/example.env b/.secrets/example.env index 985f34a..085e7fd 100644 --- a/.secrets/example.env +++ b/.secrets/example.env @@ -24,7 +24,7 @@ # blog_vps_production.env ENV_FILE=blog_vps_production.env deploy/make-release.sh # blog_vps_staging.env ENV_FILE=blog_vps_staging.env deploy/make-release.sh # -# make-release.sh reads it over any value the caller exported first, and refuses a file that group or other can read. A named +# make-release.sh reads DEPLOY_ROOT, DEPLOY_SSH_HOST, and SITE_BASE_URL from it over the caller's, and refuses a file that group or other can read. A named # file that does not exist is a hard failure rather than a fall-through. Real files live # in ~/.secrets/, never in this checkout, so no value naming a machine reaches this history. diff --git a/OPERATIONS.md b/OPERATIONS.md index ef20077..da2ebea 100644 --- a/OPERATIONS.md +++ b/OPERATIONS.md @@ -39,7 +39,7 @@ ENV_FILE=~/.secrets/blog_local_production.env deploy/make-release.sh "" "$RELEAS EXPECT_RELEASE="$RELEASE" checks/check-live-urls.sh "$SITE_BASE_URL" ``` -Name the file in both places, even when it is the default, since `make-release.sh` reads `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: +Name the file in both places, even when it is the default, since `make-release.sh` reads `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 `DEPLOY_ROOT` the script reads from that file. `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 @@ -65,7 +65,7 @@ So the bundle stamps its own version as `X-Blog-Release`, and `check-live-urls.s EXPECT_RELEASE= checks/check-live-urls.sh "$SITE_BASE_URL" ``` -Sourcing the environment file first puts the deploy root and the base URL in the environment, so no literal value is typed. `make-release.sh` then needs no arguments, because its deploy root falls back to `$DEPLOY_ROOT` and its version falls back to a timestamp. It still accepts both arguments, and the deploy workflow passes a bundle path and a version, as [Deploying](#deploying) below shows. Either form works locally, and the argument wins over the environment. +Sourcing the environment file first puts the base URL in the shell for `check-live-urls.sh`, so no literal value is typed. `make-release.sh` needs no arguments. Its deploy root falls back to the `DEPLOY_ROOT` it reads from its own file, and its version falls back to a timestamp. It still accepts both arguments, and the deploy workflow passes a bundle path and a version, as [Deploying](#deploying) below shows. Either form works locally, and the argument wins over the environment. `ENV_FILE` is set as well as sourced, and the redundancy is deliberate. The script reads its own file regardless, so leaving `ENV_FILE` off would build and install against `~/.secrets/blog_local_production.env` while the shell's `$SITE_BASE_URL` still named staging, and the run would check the staging site after publishing to the production root. The script prints the file it read, on every build, for that reason. From 96941d0e11403001d0d391ecd7bb6f991ba8c090 Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Wed, 28 Oct 2026 14:28:36 -0700 Subject: [PATCH 2/2] Name What Sourcing Supplies and What the Root Argument Overrides Co-Authored-By: Claude Opus 5.5 --- OPERATIONS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OPERATIONS.md b/OPERATIONS.md index da2ebea..bcadac0 100644 --- a/OPERATIONS.md +++ b/OPERATIONS.md @@ -65,7 +65,7 @@ So the bundle stamps its own version as `X-Blog-Release`, and `check-live-urls.s EXPECT_RELEASE= checks/check-live-urls.sh "$SITE_BASE_URL" ``` -Sourcing the environment file first puts the base URL in the shell for `check-live-urls.sh`, so no literal value is typed. `make-release.sh` needs no arguments. Its deploy root falls back to the `DEPLOY_ROOT` it reads from its own file, and its version falls back to a timestamp. It still accepts both arguments, and the deploy workflow passes a bundle path and a version, as [Deploying](#deploying) below shows. Either form works locally, and the argument wins over the environment. +Sourcing the environment file first puts the base URL, and the other values `check-live-urls.sh` reads, in the shell, so no literal value is typed. `make-release.sh` needs no arguments. Its deploy root falls back to the `DEPLOY_ROOT` it reads from its own file, and its version falls back to a timestamp. It still accepts both arguments, and the deploy workflow passes a bundle path and a version, as [Deploying](#deploying) below shows. Either form works locally, and the argument wins over the file's `DEPLOY_ROOT`. `ENV_FILE` is set as well as sourced, and the redundancy is deliberate. The script reads its own file regardless, so leaving `ENV_FILE` off would build and install against `~/.secrets/blog_local_production.env` while the shell's `$SITE_BASE_URL` still named staging, and the run would check the staging site after publishing to the production root. The script prints the file it read, on every build, for that reason.