Skip to content

ci: allow long file paths before checking out on Windows - #110

Merged
ejfine merged 1 commit into
mainfrom
allow-long-file-paths-in-windows-ci
Sep 22, 2026
Merged

ejfine merged 1 commit into
mainfrom
allow-long-file-paths-in-windows-ci

Conversation

@ejfine

@ejfine ejfine commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

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:

Workflow Job Gate
ci.yaml test use_windows_in_ci
ci.yaml executable use_windows_in_exe_ci
publish.yaml test, install-from-staging, install-from-primary use_windows_in_ci
publish_to_staging.yaml test use_windows_in_ci
release.yaml install-from-staging, install-from-primary use_windows_in_ci

What side effects does this change have?

core.longpaths is a Windows-only git setting. Other platforms accept it, store it and ignore it, so the if: runner.os == 'Windows' guard is about keeping the intent legible rather than avoiding harm — verified by setting it against a throwaway GIT_CONFIG_GLOBAL on 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.yaml also references gha_windows_runner inside the artifact-collection loops of the release job. That job downloads artifacts rather than checking out, so it is untouched.

How is this change tested?

Downstream repo

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>
@coderabbitai

coderabbitai Bot commented Sep 22, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

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 configuration

Configuration used: Repository: LabAutomationAndScreening/copier-python-package-template/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: e29ea3c2-0464-469f-91c6-55dc0f566ff7

📥 Commits

Reviewing files that changed from the base of the PR and between 2bdcd8b and eba62fd.

📒 Files selected for processing (4)
  • template/.github/workflows/ci.yaml.jinja
  • template/.github/workflows/release.yaml.jinja
  • template/.github/workflows/{% if not deploy_as_executable %}publish.yaml{% endif %}.jinja
  • template/.github/workflows/{% if not deploy_as_executable %}publish_to_staging.yaml{% endif %}.jinja

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.


📝 Walkthrough

Walkthrough

The 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.

Changes

Windows long path support

Layer / File(s) Summary
CI workflow coverage
template/.github/workflows/ci.yaml.jinja
The test and executable jobs add a Windows-only step before checkout when their respective Windows CI flags are enabled.
Release and publish workflow coverage
template/.github/workflows/release.yaml.jinja, template/.github/workflows/{% if not deploy_as_executable %}publish.yaml{% endif %}.jinja, template/.github/workflows/{% if not deploy_as_executable %}publish_to_staging.yaml{% endif %}.jinja
Release and publish jobs add the same conditional step before checkout when Windows CI is enabled.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to eba62

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)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title clearly and concisely describes the primary change: enabling long file paths before Windows checkout.
Description check ✅ Passed The description explains the implementation, affected workflows, side effects, and test context. It omits the required “Why is this change necessary?” section and provides limited testing detail, but …

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@ejfine
ejfine requested a review from zendern September 22, 2026 12:31
@ejfine
ejfine marked this pull request as ready for review September 22, 2026 12:31
@ejfine
ejfine merged commit c48ec0c into main Sep 22, 2026
27 checks passed
@ejfine
ejfine deleted the allow-long-file-paths-in-windows-ci branch September 22, 2026 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants