Insert-if-missing zsh baseline ordering across all 6 delivery mechanisms - #55
Merged
Conversation
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
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.
Summary
The
.zshrcbaseline (prompt/history/completion setup) used to be written by a single full-contentfiles:step. Several other lessons (sdkman/rbenv/pyenv/asdf/go/rust/rvm/cpan) independently append their own lines into the same.zshrc/.bashrc. Since afile:step is a full overwrite, whichever kind of step (filevsappend) a given tool happened to apply last to the same destination would silently win/wipe the other - Salt was the one tool that visibly hit this, papered over with a blanketorder: laston every append.This PR replaces the full-content write with three
appends:entries (grouped by concern: prompt setup, shell options, completion system), reusing the existingappends:/append:mechanism rather than introducing a new step type. They're attached via anoop: zsh_baselinecarrier placed in COMMON_AREA, which every tool already applies before any gated area - noneeds:/meets:coupling required for 4 of 5 tools. Salt is the exception (itsinclude:-based area pull-in doesn't reliably preserve common-before-areas by textual position), so it gets a small genericorder:passthrough field instead of the old blanketorder: lasthack.No bash/Ruby glue code was introduced to work around any tool's own gaps - where a tool was missing real support for the
nooptype (previously only exercised by the plain-bash-installer'swindows.yml), a first-class case was added to that tool's own install_step dispatcher instead.Changes
scriptbox/config/ubuntu2204.yml: splitfiles.ubuntu_default_zshrcinto 3 concern-groupedappends:entries, attached via a newnoop: zsh_baselineCOMMON_AREA carrier (order: 1).resolve_order.rb/generate_chef_databag.rb: generic optionalorder:field, passed through to every generator (only Salt's template consumes it).noopcase to each install_step dispatcher (CFEngine needed none - it already no-ops silently for any unrecognized type).install_step.jinja:order: laston every append is noworder: {{ step.get('order', 'last') }}- the baseline runs first viaorder: 1, every other append is unchanged.scriptbox/config/helpers/common.yml: fixedappend_line()(bash + PowerShell) to create the destination file if missing, rather than silently no-op'ing - a real bug this change exposed, since every prior append target was guaranteed to already exist by some other step.Test plan
rake generate:all- all 5 CM-tool generators regenerate cleanlyrake test- 76/76 passing.zshrc, in the correct internal order, before every other lesson's own appended lines, with no duplication on re-provision.