mirror of
https://github.com/Twigpine/node.git
synced 2026-11-08 15:39:37 -10:00
JATMNandClaude Opus 5.5
e2ae21795a
* chore: rebrand user-facing gitlawb references to Twigpine
Rename the product name in docs, README, CLI help/output, MCP tool
descriptions, macOS app strings, installers, npm metadata and license
headers from gitlawb/Gitlawb to Twigpine. Point GitHub links at the
renamed Twigpine org (and fix the release workflow's repository guard,
which still matched Gitlawb/node), and switch the public node hosts and
website/install URLs to twigpine.com.
Protocol and operator identifiers are intentionally unchanged
(did:gitlawb, gitlawb://, signing domains, GITLAWB_* env vars, crate
and binary names, X-Gitlawb-* headers, icaptcha and peer-network URLs);
they need a follow-up migration.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* docs: point image pulls at ghcr.io/twigpine/node and fix macOS DMG name
The release workflow publishes the container image to
ghcr.io/${GITHUB_REPOSITORY,,}, which is ghcr.io/twigpine/node since the
org rename; the old ghcr.io/gitlawb/node path no longer resolves for
anonymous pulls. Point the RUN-A-NODE docker run example, the OSS
readiness audit's claim about it, and the macOS app's generated compose
file at the published path.
The README listed the macOS DMG as "Twigpine Node.dmg", but
build-macos-app.sh writes GitlawbNode-macOS.dmg (kept on purpose), so
document the real file name.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* fix(infra): keep the AWS security group description to avoid replacement
`description` on aws_security_group is ForceNew, so renaming it forced a
replace of the in-use group on the next apply of an existing deployment.
Restore the original text and note why it must stay until a separate
infra migration.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* fix(macos): regenerate the app's compose file instead of treating it as a repo's
Config.repoPath fell back to the data directory when no repo clone was
found, and DockerCompose then picked up the compose file it had generated
there as if it belonged to a repo. The generator therefore only ran on
first launch, so upgraded installs kept their original compose, including
the old ghcr.io/gitlawb/node image, which no longer serves anonymous pulls.
repoPath now returns nil when there is no clone, and the app regenerates
its compose file whenever no repo compose is in use. Project directory and
named volumes are unchanged.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* fix(infra): default the AWS node image to ghcr.io/twigpine/node
release.yml publishes to ghcr.io/${GITHUB_REPOSITORY,,}, which is now
ghcr.io/twigpine/node; ghcr.io/gitlawb/node denies anonymous pulls, so the
default made new deployments fail to start and the upgrade command fail
on existing ones. On an existing deployment `terraform apply` only updates
the upgrade SSM document in place (user_data drift is ignored); the new
image is pulled on the next upgrade_command.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* fix(macos): keep operator edits to the generated compose, migrate only the image
e04efe4 regenerated the app's compose file on every access, overwriting
edits operators make to pass settings the generated environment block
omits (e.g. GITLAWB_OPERATOR_STRICT_MODE). Generate the file only when it
is missing; when it exists, keep it and rewrite only references to the
retired ghcr.io/gitlawb/node image, keeping tags and digests.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* fix(macos): only migrate complete ghcr.io/gitlawb/node references
Without a left boundary the migration also rewrote the retired path when
it appeared inside a longer reference, such as a registry mirror
(registry.example.com/ghcr.io/gitlawb/node), pointing it at a path the
mirror may not have.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
---------
Co-authored-by: Claude Opus 5.5 <[email protected]>
npm distribution for the Twigpine CLI
This directory packages the gl and git-remote-gitlawb binaries as the
@gitlawb/gl npm package.
It uses the optionalDependencies platform-package pattern (the same one
esbuild/swc/turbo use): the wrapper @gitlawb/gl declares four per-platform
packages as optionalDependencies, each gated by os/cpu. npm installs only
the one matching the host, and the wrapper's postinstall (install.js) copies
the binary out of it into bin/. No binaries are downloaded at install time.
packages/
gl/ @gitlawb/gl wrapper (postinstall, bin shims)
gl-darwin-arm64/ @gitlawb/gl-darwin-arm64 aarch64-apple-darwin
gl-darwin-x64/ @gitlawb/gl-darwin-x64 x86_64-apple-darwin
gl-linux-arm64/ @gitlawb/gl-linux-arm64 aarch64-unknown-linux-musl
gl-linux-x64/ @gitlawb/gl-linux-x64 x86_64-unknown-linux-musl
Publishing
Publishing is automated by .github/workflows/release.yml (the npm-publish
job) on every release-please release. That job:
- Downloads the four unix release tarballs from the
Twigpine/nodeGitHub release. - Lays
gl+git-remote-gitlawbinto each platform package. - Rewrites every
package.jsonversion(and the wrapper'soptionalDependenciespins) to the release version. - Publishes the four platform packages first, then the wrapper, with
npm publish --provenance --access public.
The committed version fields here are placeholders; the workflow is the single
source of truth and always uses the release tag. There is no manual publish step.
Windows is intentionally not published to npm — the wrapper points Windows users at the curl/PowerShell installer instead.