Repository navigation
v1.33.2 #65
v1.33.2
#65
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Fixed —
mk init --cronwrapper resolvesmkviaMK_BIN(group-npm nightly no longer goes dark) (#345)The generated nightly sync wrapper set
PATHto node's dir +~/.local/bin, but not the agent's actualmklocation. On a group-npm-only host (mk is a local dep at…/node_modules/.bin/mk— theMK_BIN, in neither of those dirs) baremkwasn't found, so reflect/reindex/render all failed withmk: command not foundand the render went stale (Taj's nightly was dark 34h; sibling of #340).mk init --cronnow bakesMK_BIN— the same varmk upgraderesolves, read from the env where the operator runs it — into the wrapper as a runtime-overridable default (MK_BIN="${MK_BIN:-<baked>}") and prepends its dir to the front ofPATH, so the wrapper invokes the agent's own binary even when the cron/systemd timer hands it a clean env with noMK_BINexported. Baked into the# mk:mk-bin=header so--updatepreserves it; falls back to node-dir +~/.local/binwhen noMK_BINis known. +5 tests (test/cron-template.test.ts) incl. a smoke-run that resolves baremkagainst the baked value under a stripped PATH with no runtimeMK_BIN(the real cron case) + a runtime-override case. No public API change — PATCH-class. (The issue's secondary —mk init --cronbaking a container memory-dir that doesn't exist on the host — is tracked separately in #347.)This discussion was created from the release v1.33.2.
All reactions