mariano/soleprint
Public Access
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

rig updates

Browse Source
This commit is contained in:
buenosairesam
2026-09-16 19:08:46 -03:00
parent 3e864aa919
commit 29e30693ea
24 changed files with 8160 additions and 977 deletions
Download Patch File Download Diff File Expand all files Collapse all files

85
rig/standalone/README.md
View File

@@ -1,69 +1,44 @@
# standalone — single files for a machine the full rig is not going to
# standalone — rig as single files, one folder per profile
Each script here does one of rig's jobs without the rest of the tree. Copy one
file onto a machine, run it, read the output. Nothing to clone, nothing to
install first.
**Everything in the `<profile>/` folders here is generated. Do not edit it.**
It is rig's own tools flattened into single self-contained files, with one
profile's configuration resolved in, for a machine the full rig is not going to.
| file | does | full-rig equivalent |
| --- | --- | --- |
| `rigdeps.sh` | installs kind, kubectl, tilt, ctlptl, jq and docker compose at rig's pins, checksum-verified, no sudo | `make deps` (`ctrl/deps.sh`) |
| `rigmini.sh` | reports how much memory the machine *advertises* and what caps it; `push` measures what it will actually *survive* | `make mem`, and the memory section of `make check` |
**These are transitional.** Where the full rig is installed, use its own
targets instead; they read `ctrl/versions.env` and the profile, which these
cannot.
## Why single files
`rigdeps.sh` carries its pins inline, because `ctrl/versions.env` is not on the
machine it is for. That makes two copies of the same versions and checksums.
`make pins` compares them and fails on any difference — `ctrl/versions.env` is
the source of truth.
`rigmini.sh` exists because on a container or managed workspace `/proc/meminfo`
reports the *host's* memory while a cgroup cap kills processes at a fraction of
it. `status` reads the caps; `push` allocates until something stops it.
## Use
**These two files are the whole setup.** No folder to create, no PATH to edit by
hand, nothing else to download first. The toolchain goes into `~/.local/bin`,
which Ubuntu already puts on PATH at login once the directory exists — so a new
shell after `install` is all it takes. If it is not on PATH, `install` says so
and prints the one line to add.
```bash
bash rigdeps.sh detect # report, change nothing
bash rigdeps.sh install dev # install into ~/.local/bin
bash rigmini.sh status # advertised memory and caps; safe
bash rigmini.sh push # allocates until it stops — not on a machine you need
```
standalone/<profile>/rigdeps.sh rig's toolchain installer (ctrl/deps.sh)
standalone/<profile>/rigmini.sh rig's memory tool (ctrl/mem.sh)
standalone/<profile>/Makefile shorthand for calling them
```
The `Makefile` beside them is **optional shorthand** for exactly those calls —
copy it along or don't; the scripts do not need it:
One folder per file in `ctrl/env.d/`. Pick the profile you mean to run and copy
that folder; nothing else from rig is needed. The scripts run without the
Makefile.
```bash
make deps # = rigdeps.sh detect (reports; installing is `make deps install`)
make mem # = rigmini.sh status
bash rigdeps.sh detect # report the host and toolchain; changes nothing
bash rigdeps.sh install dev # download, verify, install into ~/.local/bin
bash rigmini.sh status # advertised memory and what caps it; safe
bash rigmini.sh all # measure, then weigh it against this profile
make deps / make mem # the same, via the Makefile
```
If you wrap these scripts in a Makefile of your own, copy the calls from that
file rather than guessing them. `rigmini.sh` measures memory; it has no `on` or
`off`, and toggling a heavy service off for a smaller footprint is a job for the
project's own manifests, not for this script. `make selftest` in the full rig
fails if this Makefile ever calls a verb its script does not accept.
`rigmini.sh push` and `all` deliberately consume memory. Run `status` first, and
only run them somewhere other processes may be squeezed.
## Why generated
If an earlier setup already put these tools in some other directory on PATH,
remove that directory and the line that added it — do not rely on `install` to
notice. It only reports shadowing once `~/.local/bin` is itself on PATH, which on
a fresh machine it is not until the next login. After a new shell, check which
copy wins:
These used to be hand-kept copies, and they drifted: the standalone memory tool
said 2 GB per node long after rig had measured 800 MB. Now a kit is a pure
function of rig. It gains nothing rig lacks; improve rig and every kit follows.
```bash
command -v kind kubectl tilt # each should be ~/.local/bin/...
make standalone # regenerate every kit
make standalone check # fail if any kit differs from what rig generates now
```
One toolchain, in the one place everyone else will also look.
`make selftest` runs the check, so a kit left behind by a change to rig fails there
rather than on the machine it was copied to.
`rigmini.sh push` deliberately consumes memory. Run `status` first, and only run
`push` somewhere it is acceptable for other processes to be squeezed.
How the generator stays correct as rig changes shape — it knows no file, function
or variable names, only a marker, a sourcing rule and two config questions, and it
proves each kit stands alone before writing it — is in `ctrl/standalone.sh`.