From e78c97695f0a87e9805c7645d24336caa76ce1d6 Mon Sep 17 00:00:00 2001 From: Tomoki Kobayashi Date: Thu, 27 Aug 2026 08:10:04 +0900 Subject: [PATCH] End the hold: the site is main's again MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1.1.0 is on the store, so site/1.0.0 has done its job โ€” deployed, branch and environment policy deleted, and the three paragraphs that described the hold go with them. A note saying the site is held, left standing after it is not, sends the next reader looking for a branch that no longer exists. Two things in those paragraphs were not about this episode, so they stay, shortened to a sentence each: that pages.yml can deploy a ref other than main at the cost of an entry in the environment's list, which is the escape hatch for exactly this situation and now has a worked example; and that a tag's site/ is the site as of the tag rather than as of the release, which is what made v1.0.0 the wrong thing to deploy. --- .claude/skills/release/SKILL.md | 41 ++++++++------------------------- 1 file changed, 10 insertions(+), 31 deletions(-) diff --git a/.claude/skills/release/SKILL.md b/.claude/skills/release/SKILL.md index 05344c6..a5af56a 100644 --- a/.claude/skills/release/SKILL.md +++ b/.claude/skills/release/SKILL.md @@ -32,38 +32,17 @@ are deployed by hand (Actions tab, or `gh workflow run pages.yml`) once the release is out. Do not add a `push:` trigger back for convenience: that is the timing this replaced. And `cancel-in-progress: false`, because a deploy interrupted midway can leave the live site as a half-written artifact. - -**Right now the live site is deployed from `site/1.0.0`, not from main** -(2026-08-26). The trigger above was added *after* a push-triggered deploy on -2026-08-11 had already put 1.1.0's page live โ€” ๐ŸŒณ blocks you make yourself, -Apple Vision Pro, privacy ยง6 โ€” while 1.1.0 was unreleased and iOS 1.0.0 was -still in review. That branch is main with `site/` rolled back, and it is -disposable. - -**The policy page is the exception, and it is the shape to reuse.** ยง6 is what -tells App Review why the app asks to sense the room, so it had to be live -before the visionOS build was submitted โ€” and deploying main to get it would -have taken the landing page along, selling a version still in review. So -`privacy.html` alone was carried across from main onto the branch and deployed -from there. A policy describing a version that has not shipped is a policy -written ahead of time; a landing page selling one is an advertisement for -something nobody can buy. - -**What ends the hold is 1.1.0 actually being on the store** โ€” not approved, not -submitted, live. Then `gh workflow run pages.yml --ref main`, and delete the -branch, its policy **and these three paragraphs** โ€” a note saying the site is -held, left standing after it is not, sends the next reader looking for a branch -that no longer exists. The policy's id is in the environment listing, and -removing it is what stops a future deploy from having a second ref to choose -from. Two traps sit around this. Deploying from the `v1.0.0` -tag is *not* the same as deploying 1.0.0's site โ€” the tag was cut before the -app was on the store, so its page says "Coming soon" and points the badge at -GitHub; the branch re-applies the badge and the OG card on top of the tag's -`site/`. And a ref outside the `github-pages` environment's list fails in two +**It can also deploy a ref that is not main**, which is the escape hatch when +the site has to move while main is ahead of what has shipped โ€” 1.1.0's review +window was spent serving 1.0.0's landing page from a branch, with only +`privacy.html` carried across so App Review could read why the app senses the +room. What that costs is a line in the `github-pages` environment: it lists the +refs allowed to deploy (`main` and `gh-pages`), and anything else fails in two seconds with `not allowed to deploy to github-pages due to environment -protection rules`, which names the ref and nothing else: the list holds -`main`, `gh-pages` and `site/1.0.0`, tags are not in it, and it is edited -through `repos/{owner}/{repo}/environments/github-pages/deployment-branch-policies`. +protection rules`, naming the ref and nothing else. Tags are never in that list +by default โ€” and a tag's `site/` is the site as of the tag, not as of the +release, which for `v1.0.0` meant a "Coming soon" page whose badge pointed at +GitHub. The policy page states what was *measured* โ€” no accounts, no analytics, no advertising or third-party SDK, no tracking, and no networking code anywhere in the app or in TortoiseGraphics2 โ€” which is also why no