Repository navigation
tech-debt(ansible): four playbook sites still state the code-source root as a literal after #15632 #15705
Description
Left over after #15632 brought every code_source_dir fallback and every role default onto autobot.base_dir. Four sites still state the install root as a literal, and they are the last ones in the ansible tree:
| file | line | variable |
|---|---|---|
playbooks/pre-flight-code-sync.yml |
27 | git_repo_root |
playbooks/provision-fleet-roles.yml |
39 | git_repo_root |
playbooks/update-all-nodes.yml |
43 | git_repo_root |
playbooks/configure-python-provision-permissions.yml |
41 | provision_playbook |
All four are in hardcoded_values_baseline.txt, so they are recorded rather than unnoticed.
Why they were out of #15632's scope, and why they still matter
#15632 was scoped to code_source_dir fallbacks. These name a different variable, so they were correctly left alone — but they point at the same directory, and after #15632 they are the only places that still assume where it is.
That makes the divergence sharper than before rather than softer. sync-code-source.yml now writes to autobot.base_dir ~ '/code_source'; pre-flight-code-sync.yml still reads /opt/autobot/code_source. Those are the same path today and only today. The pre-flight check exists to catch a stale checkout, so a base-dir move gives you a check that validates a directory nothing is writing to any more — passing while the thing it guards is wrong, which is worse than failing.
Acceptance criteria
- The three
git_repo_rootsites derive fromautobot.base_dir, keeping any explicit override -
configure-python-provision-permissions.ymlderives itsprovision_playbookpath the same way - The four
hardcoded_values_baseline.txtentries are removed, or retuned where an occurrence survives in the same file — the baseline is shrink-checked, so a stale entry fails as loudly as a new violation - A grep for the bare literal across
autobot-slm-backend/ansible/returns nothing at all, which is the state tech-debt(ansible): two pip constraint paths restate the code_source literal instead of deriving it from base_dir #15601 asked for and could not reach while these remained - Whether
git_repo_rootandcode_source_dirare two names for one value is settled — if they are, one of them should go, and that is a decision rather than a rename
Related
- tech-debt(ansible): 14 non-pip code_source_dir fallbacks still restate the base dir literal #15632 — the fallbacks and role defaults, done
- tech-debt(ansible): two pip constraint paths restate the code_source literal instead of deriving it from base_dir #15601 — the pip constraint paths, done; its "grep returns only sites that genuinely need it" criterion is what this finishes
Activity
tech-debt(ansible): derive the git_repo_root aliases, keep the sudoer…
fix(ansible): make the code_source override authoritative for the who…
tech-debt(ansible): derive the git_repo_root aliases, keep the sudoer…
github-actions commentedon Sep 5, 2026
PR #15706 (merged to
Dev_new_gui) references this issue with a close keyword.If this issue is fully resolved, close it manually. If work remains, no action is needed.
mrveiss commentedon Sep 5, 2026
Closing on all five criteria, verified against merged code on
Dev_new_gui(PR #15706).git_repo_rootsites derive, keeping any overridepre-flight-code-sync.yml,provision-fleet-roles.yml,update-all-nodes.yml— each{{ code_source_dir | default(autobot.base_dir ~ '/code_source') }}configure-python-provision-permissions.ymlderives its path the same waygit_repo_rootandcode_source_dirare two names for one value is settled"Deploying from existing code_source at {{ git_repo_root }}". Treated as an alias that resolves to the same expressionCriterion 2 was answered "no", and that is the finding
The criterion assumed all four sites should derive. One must not.
provision_playbookdoes not restate the ansible SSOT — it mirrors a value produced on the Python side:api/code_sync.py:1623builds_PROVISION_PYTHON_PLAYBOOKfromDEFAULT_REPO_PATH,:1896runs it assudo ansible-playbook <that path>, and the NOPASSWD rule this playbook writes exact-matches that argv.code_sync.py:1628already says changing the args breaks it.Deriving it from
autobot.base_dirwould have made a third independent source for one path, and the divergence would surface as sudo refusing a command rather than as a wrong directory.Review then showed the coupling is looser than I had described. I wrote that the two agree "by coincidence" and would diverge on relocation; in fact
git_tracker.py:33readsDEFAULT_REPO_PATHfromSLM_REPO_PATH, so one environment variable moves the Python side while the literal and its sudoers rule stay put. The site comment now names that variable, and #15707 carries the missing check.A split this PR created, and fixed
Making
git_repo_roothonour the override left four pip tasks in Plays 1, 2 and 2b still reading constraints from{{ autobot.base_dir }}/code_source. Before the change both spellings were the same literal, so an override was uniformly ignored; after it, Play 0 would sync to the override while the installs read constraints elsewhere. A half-honoured override is worse than none — it succeeds against the wrong file. All four now resolve the expression themselves, sincegit_repo_rootis scoped to Play 0.Spun out
code_distributor.py:33andgit_tracker.py:33bind the sameSLM_REPO_PATHto different defaults under the same constant namefix(deploy): stop localhost plays touching the autobot mapping (#15731)…
guard(deploy): assert the two spellings of the provision playbook agr…
guard(deploy): four deploy facts stated twice, now stated once and ch…