Files

T

noconnorandClaude Opus 5 86b8e51646 Remove the docker module: dotfiles no longer installs Docker

Installing Docker Engine is a host/image decision, not a per-user
environment one. In Coder workspaces (unprivileged pods, no systemd) the
module ran get.docker.com on every start for a daemon that can never
run there. Where Docker is wanted, install it on the host or bake it
into the image.

Also drops the zshrc newgrp-docker hook that existed only for this
module's group change, and the docs/skills references to docker/.
docker-rootless-cgroup/ (configures Kasm's existing rootless daemon)
and bin/'s kind gate (detects a daemon) stay.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-19 13:39:59 -04:00

2.9 KiB

Raw Permalink Blame History

name, description

name	description
bump-pinned-version	Use when upgrading a pinned version anywhere in this repo — a CLI in bin/install.sh, NODE_VERSION in node/install.sh, or an npm-pinned MCP server in mcp-config/opencode.gateway.json. Covers where the pins live, how to verify the new release actually exists, and the supply-chain reasoning behind pinning.

Bumping a pinned version

Everything in this repo is version-pinned on purpose. Nothing floats.

Where the pins live

Pin	Location	Shape
CLI tools	`bin/install.sh`	`ver=v1.2.3` inside each `install_<name>()`
Node.js	`node/install.sh`	`NODE_VERSION="v24.18.0"`
MCP servers	`mcp-config/opencode.gateway.json`	`["npx", "-y", "pkg@0.0.10"]`
oh-my-zsh	`zsh/`	installed from upstream script — not pinned

Grep before assuming: grep -rnE 'ver=|_VERSION=|@[0-9]+\.[0-9]+' --include='*.sh' --include='*.json'

Why these are pinned

npx -y <pkg> executes whatever the registry serves at that moment. The MCP servers receive your Gitea and Proxmox tokens ({env:GITEA_KEY} and friends are passed into the spawned process), so an unpinned server is a live supply-chain path to your credentials. node/install.sh says this out loud in its header. A version bump is a supply-chain decision, not a chore — when bumping an MCP server or Node itself, skim the upstream changelog for a maintainer change or a new network dependency, and say what you found.

Doing the bump

Verify the release exists before editing. Don't trust the model's memory of version numbers — check upstream (gh release list, the GitHub releases page, npm view <pkg> versions, or nodejs.org/dist).
Verify the asset URL still resolves. Projects rename assets between releases. Build the exact URL the script will request and check it:
```
curl -fsSLI "https://github.com/derailed/k9s/releases/download/v0.51.0/k9s_Linux_amd64.tar.gz"
```
A 404 here becomes a hard bootstrap failure under set -eu.
Match the upstream tag exactly — v1.2.3 vs 1.2.3 matters, because have_version string-compares against the .versions stamp. Get it wrong and the tool reinstalls on every single bootstrap, silently.
Bump one thing per commit. When a box breaks after a bootstrap, the commit log should say which upgrade did it.

Verifying

The .versions stamp is what makes the bump observable:

cat ~/.local/bin/.versions/<tool>    # old version
./bin/install.sh                     # should download, not skip
cat ~/.local/bin/.versions/<tool>    # new version
./bin/install.sh                     # should now say "already installed"

If the second run re-downloads, the ver= string and the stamp disagree — that is the tag-format bug from step 3.

For an MCP server bump, restart opencode and confirm the server actually comes up. A dead MCP server is reported only as missing tools, so it looks like a model problem rather than a version problem.

2.9 KiB Raw Permalink Blame History