CI diagnostic: Windows test_cli_configoverrides failure - #287
Open
yarikoptic wants to merge 6 commits into
Open
Conversation
Windows `test-datalad (master|maint|release)` all fail on the single
`datalad/cli/tests/test_main.py::test_cli_configoverrides` test with
`assert 1 == 0` (datalad `run` exits 1 instead of 0). The pytest run
patches sys.stdout / sys.stderr, so the actual datalad/git error
never reaches the workflow log.
Reproduce the failing scenario before pytest and let all output flow
through, so we can see exit codes, stderr, and env from three angles:
1. exact test invocation
(`datalad -c ... run -d ... 'git config ...'`)
2. same but with `env | grep` + `git config --show-origin` inside
the run subshell, to see whether the override actually made it
into GIT_CONFIG_PARAMETERS
3. bare `git config` with a hand-set GIT_CONFIG_PARAMETERS, to rule
out git's own handling of the env var on Windows
Only touches the Windows workflow; macOS / Ubuntu / macOS-ARM64
builds have no path-triggered dependency on this file so they don't
re-run.
Co-Authored-By: Claude Code 2.1.221 / Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ORE MERGE To iterate on test_cli_configoverrides diagnosis: - skip `test-annex` jobs entirely (`if: false`) - reduce `test-datalad` matrix to `[master]` (all three variants fail identically, so one is enough) - pass `--pyargs datalad.cli.tests.test_main -k test_cli_configoverrides` to pytest so the run finishes in ~2 min instead of ~90 Revert this commit before this PR is mergeable. Co-Authored-By: Claude Code 2.1.221 / Claude Opus 4.7 (1M context) <noreply@anthropic.com>
windows-2025 runners put the actions workspace on D: while the default
user-profile TEMP is on C:. Python's `tempfile` (and datalad's
`@with_tempfile`) create datasets on C:, but pytest CWD and
`datalad run -d <path>` execute on D:. `datalad run` then computes
`os.path.relpath(dataset, cwd)` which, on Windows, raises
ValueError: path is on mount 'D:', start on mount 'C:'
surfaced by datalad as `[ERROR] path is on mount 'D:', start on mount 'C:'`
and an exit code of 1. That's what has been failing
`test_cli_configoverrides` (and would fail any other test that
combines `@with_tempfile` with `datalad run -d ...` on this runner).
Fix in-workflow by pointing TMP / TEMP / TMPDIR at `$RUNNER_TEMP`
(which lives on D:), so tempfiles and CWD share a drive.
Datalad-side bug tracked upstream — comment updated with issue URL
once filed.
Co-Authored-By: Claude Code 2.1.221 / Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Move the previously yaml-only workaround (e2b5693) into the shared workflow template so any future test-datalad-on-Windows regeneration carries it, and regen `build-windows.yaml`. ## Story windows-2025 GHA runners put the actions workspace on D: while the default user-profile TEMP is on C:. Python's `tempfile` (and datalad's `@with_tempfile`) create datasets under C:\...\Temp; pytest CWD and `datalad run -d <path>` operate on D:. `datalad run` then calls `os.path.relpath(dataset, cwd)` which — on Windows only — raises ValueError: path is on mount 'D:', start on mount 'C:' Datalad catches and logs `[ERROR] path is on mount 'D:', start on mount 'C:'`, returns exit 1. Symptom: `datalad/cli/tests/test_main.py::test_cli_configoverrides` fails with `assert 1 == 0` on Windows only; captured stdout/stderr in `run_main` hides the actual error, which is why prior CI runs looked opaque. Diagnosed on PR #287 via a temporary step reproducing the invocation outside pytest — the three attempts showed: 1. datalad `-c ... run -d ...` → exit 1, [ERROR] cross-mount 2. same, dumping env inside subshell → exit 1, same error 3. bare `git config` with hand-set GIT_CONFIG_PARAMETERS → exit 0, prints `unique` Confirming: git 2.55 on windows-2025 handles GIT_CONFIG_PARAMETERS just fine; failure is entirely in datalad's cross-drive `run -d` handling. Not a git-annex regression. Fix in-workflow (until datalad handles cross-drive paths itself) by pointing TMP / TEMP / TMPDIR at `$RUNNER_TEMP/dltmp` — same drive as the workspace, so `os.path.relpath` never crosses mounts. Only applies inside the `{% elif ostype == "windows" %}` block of test-datalad; no effect on ubuntu / macos. Upstream datalad-side bug to be filed; reproducer and workaround tracked in this PR. Co-Authored-By: Claude Code 2.1.221 / Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Upstream `stack.yaml` (origin/upstream/master) now includes
`- magic-1.1` in extra-deps; blindly appending our sha256-pinned form
duplicates the dependency and stack aborts with:
Error: [S-5470]
The same package name is used in more than one project package or
extra-deps.
magic used in:
* magic (from Hackage)
* magic (from Hackage)
Guard the append with `grep -qE '^- magic(-|@|$)' stack.yaml ||`
so we only add the pin when upstream doesn't already provide one.
Also handles the reverse case if upstream later drops it.
Windows / macOS / macOS-ARM64 all regenerated from the shared
template.
Co-Authored-By: Claude Code 2.1.221 / Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…rkaround) Prior attempt (9ac207c) tried to make datalad's cross-drive `os.path.relpath` ValueError go away on windows-2025 by pointing TMP / TEMP / TMPDIR at `$RUNNER_TEMP/dltmp` (D:). That fixed test_cli_configoverrides but exposed two follow-on problems: 1. `test_install_from_tilda` still failed with `ValueError: path is on mount 'D:', start on mount 'C:'`. It resolves `~/…`, which expands via HOME (C:\Users\runneradmin) — TMPDIR moving to D: didn't help. 2. `test_ExtractedArchive` / `test_ArchivesCache` failed with `WinError 123` on path `\\?\D:\a\_temp/dltmp\datalad_temp_…`. Windows extended-length paths (`\\?\` prefix) require pure backslashes; our TMPDIR of `D:\a\_temp/dltmp` (mixed) breaks that. Root issue: HOME + user-profile TEMP live on C:, workspace on D:. Any datalad code path that relpath's between the two blows up. Rather than dragging both TMP *and* HOME onto D: (invasive, would also move ssh keys the workflow set up earlier under `~/.ssh`), do what datalad's own AppVeyor CI does: keep everything on C: by running pytest from a C: directory. Then tempfile default + HOME + CWD all share one drive, and no cross-drive relpath is ever attempted. Template: - drop the `Point tempdir to workspace drive` step - `Run datalad tests`: on Windows, `cd "$HOME/dl-testhome"` (C:) with `-c "$GITHUB_WORKSPACE/datalad/tox.ini"` (absolute). On ubuntu / macos, keep the pre-existing `__testhome__` behaviour verbatim. Windows / Ubuntu / macOS / macOS-ARM64 all regenerated from the shared template. Co-Authored-By: Claude Code 2.1.221 / Claude Opus 4.7 (1M context) <noreply@anthropic.com>
yarikoptic
force-pushed
the
bf-diag-configoverrides
branch
from
August 7, 2026 18:28
16b898f to
3c05537
Compare
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.
Important
Drop the TEMP commit before merge.
Summary
Windows
test-dataladfails on a single test —test_cli_configoverrides— which passes on Ubuntu with the same git-annex and on datalad's own AppVeyor Windows CI with an older git-annex (10.20230126, 2023‑01). The failure isassert 1 == 0(dataladrunexits 1), but pytest patches stdout/stderr so the actual error never reaches the log.This PR adds a diagnostic step that reproduces the failing invocation outside pytest so we can see exit code + stderr, and temporarily scopes the Windows CI down so iteration is ~2 min instead of ~90.
Once we have signal, next step is likely to bisect git-annex.
Commits
CI: add Windows diagnostic for datalad test_cli_configoverrides failureTEMP: shrink Windows CI to only the failing datalad test — REVERT BEFORE MERGETest plan
5feffcda0fbefore merge