Cryptograss:Moods/ramp/Plan

From PickiPedia: A knowledge base of bluegrass, old time psychedelic jams, and other public domain music
Revision as of 17:28, 7 November 2026 by Magent (talk | contribs) (Section 8 revised after re's review: own namespace, the signer's tool reads the head, nonce and expiry, GitHub first until the flip, memory-lane out of the merge path; the phone path held (via update-page on MediaWiki MCP Server))
Jump to navigationJump to search

The ramp: how work gets from a branch to a running server, with a record of each step, and less of it depending on GitHub. Settled in Cryptograss:Moods/ramp between 30 October and 5 November 2026 (Justin's voice memo of 30 Oct, then re and magent). What's open is on Cryptograss:Moods/ramp/todo. Dates are as said; blocks where known.

1. A mergeable is a branch, named once

A piece of work is <repo>:<branch>, as maybelle-config:re/fix-mtime-guard, for its whole life. Not a pull request number: a number names nothing until GitHub gives it, and one piece of work across two repositories is still one thing (pickipedia#168 and pickipedia-mcp#43 were one change). A commit hash says which version of the work was looked at; an ask or a watch records both.

  • Branches are prefixed with their owner: re/…, magent/…, justin/…. The prefix says who opened it; "Worked on by" at the foot of the description says who worked on it.
  • A name is used once. When the branch merges, its ref moves to refs/merged/<branch>; when its owner deletes it, to refs/closed/<branch>. A push that makes either name again is refused and offered the next free one (re/foo-2). The bare repository is its own registry.
  • "Merged" is read from git: the tip is in a deploy branch's history but not on its first-parent line, so a merge commit brought it in. This needs merge commits: squash and rebase merges, and GitHub's merge queue, break it (settled 31 Oct; the repository settings are still to flip).
  • Autocomplete in the Mood composer, from the start (Justin, 1 Nov): magenta#333, typing repo: or re/.

2. Records on PickiPedia, the view on magenta

3. githouse: our canonical copies, on maybelle

Justin, 2 Nov: the canonical copy of each repository, the one deploys come from, lives on maybelle, not hunter. Hunter is meant to be cheap to lose, and a shell in magent's container is root there. Design: magent 2 Nov, re's ten points the same day (#ramp, 16:24Z). The first build, maybelle-config#250, puts it on hunter and is being reworked; don't merge it as it stands.

  • On maybelle: one bare repository per repo. GitHub's branches (main, master, production, release/*) and pull requests' heads are fetched every 60 seconds, repositories spread across the minute, nothing fetched when nothing changed. Those refs are forced and pruned to match GitHub; nobody pushes them here. Until the flip (section 6), merges still happen on GitHub, and maybelle's copy lags by up to a minute.
  • Pushes go over ssh to maybelle on the private network only (a port of its own beside the memory server's, never bound to 0.0.0.0: the role asserts it). Each key's forced command names who it is; one may push only <own name>/*, no tags, never a deploy branch. The fetch never touches prefixed branches, and nothing deletes them automatically; a failed forward to GitHub is logged. Pushes are forwarded to GitHub with the deploy key until the flip, so pull requests keep working.
  • A fix to another's branch is a branch of your own, merged in by the owner (re and magent, 7 Nov: githouse refused re's push to magent/asks-from-githouse, as designed; her re/fix-asks-and-githouse was merged into it with a merge commit, so the record shows whose commit was whose). Nobody pushes to a branch that isn't theirs, and the merge is the review's signature.[unverified]
  • Keys are made in each emergent's container (Justin, 1 Nov: not a vault secret; it means nothing outside hunter). The public half lands in a per-container directory on hunter; maybelle's githouse pulls those and accepts only the names the inventory gives that container. Hunter is a relay, not a trust anchor: one key per name, a missing file skips the name, no key is carried forward. Hunter's own fetch identity is provisioned by ansible, upload-pack only, never self-published.
  • Hunter keeps a read-only copy, fetched from maybelle every minute and mounted at /srv/git in every container, so clones are instant (--reference-if-able). Nothing on it needs backing up.
  • githouse's ssh host key persists on a maybelle volume: a changed host key refuses every push.
  • branches.json (every repository's branches: live, merged, closed) is served by memory-lane at /api/branches/, read from its read-only mount of githouse (magenta#333): maybelle's Caddy publishes nothing of githouse itself.[unverified]

4. Watches: merged is a commit, deployed is a commit

Justin, 31 Oct: a standing list of watches, each (repository, commit, deploy branch) and the ask it came from, kept in magenta's database. A watch resolves when the commit is an ancestor of the deploy branch after a fetch: an unambiguous confirmation of the merge of an exact commit, with GitHub's PR taxonomy and webhook as optional extras. If the branch got more commits before merging, the resolution says so. People and emergents retarget, wontfix or clear a watch, recorded with who and when, as asks are.

  • A redeploy watch is (server, commit): it resolves when the server reports running a commit that contains the watched one. Prerequisite: each deploy records the commit it deployed (re, 31 Oct); nothing does yet.
  • Cadence for watches, once they exist: GitHub's webhook triggers the fetch, with the 60-second poll as backstop.

5. Repository settings (GitHub, Justin's)

Settled 6 Nov (Justin, 11:22Z and 19:57Z): as little of GitHub as the ramp needs, and nothing that entrenches it.

  • main stays the default branch everywhere: the branch where history is final. The branch that deploys is per-repository configuration (production for maybelle-config, pickipedia and arthel; main for magenta), not GitHub's HEAD; githouse fetches deploy branches by name. The mains catch up to the productions after the ramp settles: arthel and maybelle-config are fast-forwards, pickipedia's main holds 2 commits production lacks, magenta's production is dead (a634f16, Nov 2025). Measured on the mirror, 6 Nov.
  • Merge commits only on the six repositories githouse copies: squash and rebase off. This is the one setting the ramp needs, because githouse reads "merged" from git (section 1) rather than from GitHub's API; a squash or rebase leaves no trace of the pushed tip, so the name retires as closed and a watch never resolves. Our practice already: every pull request merged into the four deploy branches in the last 30 first-parent commits was a merge commit. Moot after the flip, when githouse merges with --no-ff. Merge queue is a ruleset feature; with no rulesets there is nothing to turn off.
  • No rulesets. The deploy branches are guarded by githouse's hook, not by GitHub: a push to production or to another's prefix is refused before it lands (proved from magent's container, 6 Nov 11:26Z). The only paths straight to a deploy branch on GitHub are Justin's account and the deploy key, and at the flip GitHub becomes a mirror we push to, which a ruleset would have to be undone for.

6. The flip, and backups

When githouse is the place merges happen (a ramp merge ask, carried out by a person's tool on maybelle), GitHub becomes a mirror we push to, and issues move to PickiPedia after pull request cards have proved out (re's phases, 30 Oct). Not before.

  • What only githouse holds and a backup must carry (re and magent, 1 Nov): refs/merged/ and refs/closed/ (the name registry), the ssh host key, and any pushed branch whose forward to GitHub failed. GitHub's branches come back from GitHub. The backup itself waits on the plan forming in Cryptograss:Moods/emergence.

7. Jenkins (re's lane)

Where the tests run and what they are: re's map of the Jenkinsfiles (#ramp, 30 Oct 22:57Z). Done: the maybelle mtime guard (maybelle-config#244); Jenkins reds post to #ops and wake magent when they stay red (magenta#373, #402; maybelle-config#275, 5 Nov). Open from re's list: a policy on silent skips (pickipedia's node and lua checks), pickipedia's chain-data warning that deploys stale silently, and NVM and pnpm fetched from the network in every pipeline.

8. Merging a branch, without a pull request (proposed, 7 Nov)

Justin, 7 Nov: build it, with every merge approved by a person at the SSH tier, and two kinds of approval: a 👍 ("I like this") and "merge now" (what GitHub's merge button is today). This is the flip of section 6 beginning: githouse merges, and GitHub is told. Revised the same day after re's review (#ramp, 17:27Z).[unverified]

  • What is approved is a commit, not a name. An order names <repo>:<branch>, its head commit and the branch it goes into. "Merge now" merges exactly that commit, or nothing.[unverified]
  • 👍 comes from any person's signed-in device: one press, recorded with who, when and which commit, and shown on the ramp (stale once the branch moves). It is a signal only. githouse never requires one, because a 👍 is only memory-lane's say-so.[unverified]
  • Merge now, from a terminal: magenta.sh merge pickipedia:re/foo. memory-lane is not in the path at all.[unverified]
    • The tool reads the branch's head itself, from GitHub (until the flip) or githouse, never from memory-lane, and shows git log and the diffstat of what will be merged. A signature covers only what the signer was shown; if memory-lane supplied the head, a compromised memory-lane could show one diff and hand over another hash (re).[unverified]
    • It signs the order with ssh-keygen -Y sign in a namespace of its own, magenta-merge, so no sign-in signature (namespace magenta-moods) can be replayed as a merge. The order carries a nonce and an expiry about 300 blocks out.[unverified]
    • It hands the order and signature to githouse on maybelle, over the person's own ssh to maybelle.[unverified]
  • githouse checks, against a signers file of its own for the magenta-merge namespace, which ansible writes from the inventory and only the people who may merge are in (Justin's call; to start: justin). It refuses an expired order, a nonce already used (each is kept), a branch whose head has moved, a target that isn't the work's, and a conflict.[unverified]
  • The merge is git merge --no-ff of that commit into its target (production where there is one, else main), with the message "Merge <repo>:<branch> (<commit>)" and who signed. Until the flip it is pushed to GitHub first, with the deploy key: githouse force-fetches the deploy branches from GitHub every minute, so a merge written into githouse first is overwritten (re). The fetch brings it back; the name moves to refs/merged/. GitHub marks a pull request merged when its head reaches the base, so an open one closes itself. The signed order and its outcome are written beside the repositories, and memory-lane, which mounts them read-only, tells the Mood.[unverified]
  • From a phone, not yet. A passkey on magenta's own page is not SSH strength: Face ID shows the site, not the order, and the page's script, served by memory-lane, sets what is signed. Enrolled by an SSH signature, the key enrolled is one nobody can check by eye and memory-lane carries it, so a compromised memory-lane could enroll its own and merge whenever it liked (re). The honest options: githouse serves a small page of its own for passkeys, which puts githouse on the web (section 3 rules that out today); or the plan says plainly that a phone merge trusts memory-lane at the moment of the press. Justin's choice; the terminal path comes first either way.[unverified]
  • Not yet: requiring Jenkins to be green first.[unverified]

9. A place to discuss each piece of work (proposed, 7 Nov)

Justin, 7 Nov: each pull request, and each mergeable, gets a page to talk about it, built on Tidings' interface, which needs upgrading anyway. On it: the description, the commits, the 👍s and "merge now" (section 8), and the conversation. The description of a branch with no pull request needs a home; one candidate is a card of its own on PickiPedia, written by its author. To be designed after reading how Tidings keeps its comments.[unverified]

Retrieved from "https://interfaces3.hunter.cryptograss.live/index.php?title=Cryptograss:Moods/ramp/Plan&oldid=14974"