fix(setup): apply ~/.dot-files before the full bootstrap - #87
Merged
Conversation
mise validates every [dotfiles] source before applying any entry, and every source except ~/.dot-files itself is written as ~/.dot-files/... -- so on a fresh machine the dotfiles stage aborted with "sources do not exist" even though the entry that creates it was right there in the list. It never surfaced locally because ~/.dot-files already existed from before the migration; the first real run of the bootstrap workflow caught it. setup.sh now applies that one entry on its own first. Targeting a single entry validates only that entry, and going through mise rather than a raw `ln` keeps the path declared in exactly one place -- the config. Also refactor setup.sh so CI calls it instead of reimplementing it: - --no-clone uses the checkout already in place, and fails loudly when it is absent rather than cloning main and testing the wrong code - --prepare-only stops before the expensive `mise bootstrap`, which is what lets the per-PR job share the code path without paying for a full install The validate job had hand-rolled linking that created a ~/.dot-files setup.sh did not, so the cheap tier stayed green while a real bootstrap failed. Both jobs now shell out to setup.sh, so the two cannot drift apart again. - bootstrap job passes --no-clone so a bad symlink fails instead of silently testing main - usage text is inlined rather than sed'd out of $0: zsh rebinds $0 to the function name inside a function, and $0 is not a file when piped from curl
MISE_AQUA_REGISTRIES under [env] is never read by mise. [env] populates the shell environment, which happens long after mise has resolved its own settings, so the personal registry stayed invisible and every `aqua:djgoku/...` install failed with "no aqua-registry found". Moved to [settings.aqua] registries, which mise does read. This was not a CI-only problem: `mise ls-remote aqua:djgoku/misemacs-emacs-master` failed locally too. It went unnoticed because the tool was already installed, so nothing ever had to resolve the registry again. Add a guard to the validate job. `mise bootstrap --dry-run` reports "would install" without contacting a registry, so it stayed green while a real bootstrap died at the tools stage. `mise settings get aqua.registries` is the deterministic check -- it errors with "Setting [aqua.registries] is not set" if the value ever drifts back under [env]. ls-remote runs alongside it to exercise the network path, though that half is only meaningful on a cold runner: a warm local aqua cache answers it even with the setting removed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mise validates every [dotfiles] source before applying any entry, and every source except ~/.dot-files itself is written as ~/.dot-files/... -- so on a fresh machine the dotfiles stage aborted with "sources do not exist" even though the entry that creates it was right there in the list. It never surfaced locally because ~/.dot-files already existed from before the migration; the first real run of the bootstrap workflow caught it.
setup.sh now applies that one entry on its own first. Targeting a single entry validates only that entry, and going through mise rather than a raw
lnkeeps the path declared in exactly one place -- the config.Also refactor setup.sh so CI calls it instead of reimplementing it:
mise bootstrap, which is what lets the per-PR job share the code path without paying for a full installThe validate job had hand-rolled linking that created a ~/.dot-files setup.sh did not, so the cheap tier stayed green while a real bootstrap failed. Both jobs now shell out to setup.sh, so the two cannot drift apart again.