Repository navigation
ci: allow long file paths before checking out on Windows - #110
Conversation
Windows defaults to a 260 character path limit, and a checkout that cannot write a file fails the job before any step of it runs. Tooling that names files after the tests they belong to reaches that limit without the names being unreasonable, so a generated project with Windows runners can find its backend unit tests never running at all. The config has to be set before the checkout writes the files, so it leads every job that can run on Windows rather than living in a shared action. Jobs whose runners are chosen by matrix only get the step when use_windows_in_ci is set, so a project without Windows runners carries nothing dead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: LabAutomationAndScreening/copier-python-package-template/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe workflow templates now enable Git long paths before checkout when Windows runners are selected. The change covers CI, release, and publish jobs, with template flags controlling whether the step is rendered. ChangesWindows long path support
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to Windows workflows enable Git long paths before checkout only when configured for Windows, with reported rendering checks covering placement and flag behavior. No actionable merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Link to Issue or Message thread
Same change as LabAutomationAndScreening/copier-nuxt-python-intranet-app#233
How does this change address the issue?
Each site is gated by whichever flag decides that job's runners, so a project carries the step only where it can run on Windows:
ci.yamltestuse_windows_in_cici.yamlexecutableuse_windows_in_exe_cipublish.yamltest,install-from-staging,install-from-primaryuse_windows_in_cipublish_to_staging.yamltestuse_windows_in_cirelease.yamlinstall-from-staging,install-from-primaryuse_windows_in_ciWhat side effects does this change have?
core.longpathsis a Windows-only git setting. Other platforms accept it, store it and ignore it, so theif: runner.os == 'Windows'guard is about keeping the intent legible rather than avoiding harm — verified by setting it against a throwawayGIT_CONFIG_GLOBALon Linux and confirming git carries on normally.The step writes to the runner's global git config, which is per-job and discarded with the runner.
release.yamlalso referencesgha_windows_runnerinside the artifact-collection loops of thereleasejob. That job downloads artifacts rather than checking out, so it is untouched.How is this change tested?
Downstream repo