Fix Windows ct-registry: OpenSSH client + cache ordering - #66
Merged
Conversation
Removes the runner.os != 'Windows' guard on the Add ct-registry step to test whether julia-actions/add-julia-registry@v2 now works on windows-latest (the exclusion predates the v1->v2 bump and its reason was never recorded). Experimental branch, not merged to main yet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
windows-latest runners ship the ssh-agent Windows service with StartupType Disabled, so add-julia-registry's ssh-agent.exe invocation fails with "unable to start ssh-agent service, error :1058" (ERROR_SERVICE_DISABLED). Enable it explicitly first. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the Windows-service-enable workaround: add-julia-registry calls bare ssh-agent/ssh-add/ssh-keyscan (PATH lookup, not a hardcoded path), which resolves to Windows' System32 OpenSSH port by default. That port (a) treats a bare ssh-agent invocation as a service start rather than forking an agent, and (b) is old enough to fail negotiating GitHub's sntrup761x25519-sha512@openssh.com post-quantum KEX during ssh-keyscan. Git for Windows ships its own MSYS2-based OpenSSH that behaves like the Unix tools these actions expect and is already present on GitHub-hosted Windows runners; prepend it to PATH instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
julia-actions/cache also restores a cached ~/.julia/registries, but logs "Julia depot registries already exist. Skipping restoring of cached registries..." whenever a registry-adding step already ran first, per its own guidance: "Please ensure that julia-actions/cache precedes any workflow steps which add registries." With Add ct-registry running first, the (large, ~700MB) General + ct-registry registries were being freshly git-cloned on every single run instead of ever being cached — likely the dominant cost of the slow Add ct-registry step observed on Windows, and probably wasting time on every OS. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 tasks
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.
Summary
Enable
ct-registryonwindows-latest(previously excluded viarunner.os != 'Windows', with no recorded reason).julia-actions/add-julia-registryinvokes baressh-agent/ssh-add/ssh-keyscan(PATH lookup), which resolves to Windows' System32 OpenSSH port by default. That port:ssh-agentinvocation as a Windows-service start rather than forking a background agent (unable to start ssh-agent service, error :1058/ERROR_SERVICE_DISABLED), andssh-keyscan github.comcannot negotiate thesntrup761x25519-sha512@openssh.compost-quantum KEX GitHub now offers (choose_kex: unsupported KEX method).Git for Windows ships its own MSYS2-based OpenSSH client that behaves like the Unix tools these actions expect, and is already installed on GitHub-hosted Windows runners — prepend it to
PATHinstead of touching the Windows service.Move the Julia cache steps before
Add ct-registry.julia-actions/cachealso restores a cached~/.julia/registries, but logsJulia depot registries already exist. Skipping restoring of cached registries...and self-documents: "Please ensure thatjulia-actions/cacheprecedes any workflow steps which add registries." WithAdd ct-registryrunning first, the registries (General +ct-registry, ~700MB) were being freshly git-cloned on every single run, on every OS, instead of ever being cached.Verified on
CTDirect.jl#614with an experimental caller pointed at this branch:Add ct-registrynow succeeds onwindows-latest(both 1.10 and 1.12), alongside aubuntu-latestbaseline.Test plan
test-cpu-githubjob against this branch (runs_on: ["ubuntu-latest", "windows-latest"],use_ct_registry: true) —Add ct-registry,Build Julia packagesucceeded on all 4 matrix entries.Run testsalso passes end-to-end (in progress at PR creation time).🤖 Generated with Claude Code