Repository navigation
cli-plugins/manager: remove legacy system-wide cli-plugin path - #6713
Merged
Merged
Conversation
commit 4d3a76d updated the list of directories for discovering CLI plugins, adding `%ProgramFiles%\Docker\cli-plugins` for system-wide plugins. For backward compatibility, the `%PROGRAMDATA%\Docker\cli-plugins` was kept, however, this location is no longer used, and not generally recommended for storing non-data content (such as CLI plugin binaries). From the [ProgramData] documentation: > ProgramData specifies the path to the program-data folder (normally C:\ProgramData). > Unlike the Program Files folder, this folder can be used by applications to store > data for standard users, because it does not require elevated permissions. It also mentions "It can’t contain any serviceable components.", effectively meaning that these paths should not contain data that is managed (through updates etc.), making it a poor choice for installing "system wide" CLI plugins. This patch removes the path from the list, given that this location is no longer used by Docker Desktop, and the CLI-plugin API is considered an internal implementation (since 459c608). [ProgramData]: https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-folderlocations-programdata Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
thaJeztah
added
impact/changelog
kind/refactor
robmry
approved these changes
Dec 18, 2025
Member
Author
|
Thx! I'll bring this one in, but feel free to tweak the release-notes, @vvoland |
This was referenced Mar 5, 2026
4 of 5 tasks
This was referenced Mar 6, 2026
This was referenced Mar 7, 2026
This was referenced Oct 2, 2026
This was referenced Oct 9, 2026
This was referenced Oct 13, 2026
sledovatel61
added a commit
to sledovatel61/HR-Manager
that referenced
this pull request
Oct 15, 2026
Симптомы на пилотной машине: значок вечно «Запускается», «Предпроверка не
пройдена: compose…» без причины, десятки powershell.exe, vmmemWSL ≈ 1.8 ГБ.
Разбор первопричин — docs/windows-installer-stability-2026-10-12.md; поведение
после исправлений — infra/windows/README.md («Ревизия стабильности установщика
(12.10.2026)»); ручная приёмка — docs/WINDOWS_ACCEPTANCE_CHECKLIST.md, раздел K.
D1 Внешние команды: асинхронное чтение stdout/stderr (без deadlock при полном
буфере), WaitForExit(timeout), классы таймаутов (пробы 60 с, операции со
стеком 900 с, сборка образов 3600 с, прочие 120 с, остановка дерева 20 с),
по таймауту — остановка ДЕРЕВА процессов (taskkill /PID <pid> /T /F) и
структурированный результат ExitCode 124 + TimedOut + причина в stderr и
журнале. Ожидание повышённого установщика Docker ограничено (3600 с) и его
НЕ убивает. Прежние ожидания (Docker Engine 300 с, Docker Desktop 300 с,
готовность приложения 180 с) не изменены — закреплено тестом.
D2 Единственность цикла движка: отдельный мьютекс Local\HRManagerPilotEngineCycle
(переопределяется HRM_ENGINE_CYCLE_MUTEX), проверка «операция уже идёт»
(Test-HrmEngineOperationInFlight) и честный результат state="busy" +
already_running; значок проверяет ту же функцию ПЕРЕД порождением скрытого
процесса. Два входа подряд дают один цикл.
D3 Блокировка действия не «протухает» по возрасту, пока процесс операции жив;
затянувшаяся операция (> 60 мин) помечается stalled: журнал + supervisor.json
error с кодом action_stalled, pid и действием для человека. Мёртвый pid —
блокировка снимается с записью причины.
D4 Значок: тики не накладываются, в Docker значок не идёт при идущей операции,
интервал зависит от состояния (5/30/60 с) — в покое 2 опроса в минуту при
критерии «не больше 4».
D5 Test-HrmComposeVersion различает cli_missing / plugin_missing /
version_unparsable / version_old / probe_failed / ok, перечисляет проверенные
каталоги плагинов и честно помечает, что Docker CLI 29.2.0+ не ищет
C:\ProgramData\Docker\cli-plugins (GHSA-p436-gjf2-799p, docker/cli#6713).
Проверка НЕ ослаблена до предупреждения. Сравнение версий числовое
(Compose 5.1.0 больше 2.24).
D6 Резолвер CLI контейнеров: собирает всех кандидатов, выбирает по правилу
«тот же корень установки, что и Docker Desktop → наибольшая версия файла →
самая свежая дата файла → прежний порядок», логирует все найденные пути и
версии, отдаёт факты (Get-HrmDockerCliFacts) для диагностики и журнала.
D7 Установка не завершается «наполовину»: compose и конфигурация проверяются ДО
записи installed.json (и в ветке повторной установки), отказ пишет
supervisor.json error с причиной; значок показывает «Ошибка» с действием, а не
вечное «Запускается»; после трёх подряд отказов автоматические повторы
останавливаются (failure_count), уведомление обрезает причину, сохраняя
действие.
D8 Наблюдатель канала: мёртвый спавнер Start-HrmChannelWatcherProcess удалён,
Start-HrmChannelWatch ограничен (-MaxCycles/-MaxMinutes и переменные
окружения), останавливается файлом channel-watch.stop и выходит при замене
pid-файла; комментарий в installer.iss приведён в соответствие с реальностью.
D9 vmmemWSL: факты в диагностике (wsl_memory_mb, wsl_memory_processes,
host_memory_total_mb, host_memory_free_mb), ожидаемый диапазон 1–2 ГБ описан в
README. Движок не удаляет окружение пользователя, не вызывает
wsl --shutdown/--unregister и не правит .wslconfig.
D10 Пункт меню «Открыть HR Manager» больше не отказывает сам себе: процесс
операции входит повторно в блокировку, переданную ему значком (action="engine").
Этап 1 сбора данных с пилотной машины:
infra/windows/tools/Collect-HrmPilotFacts.ps1 (кандидаты CLI с --version,
docker compose version --short с полным stderr и кодом возврата, каталоги
плагинов, docker info, wsl --status/--list --verbose, память vmmemWSL,
compose ps -a, все powershell.exe с ParentProcessId/CreationDate/CommandLine,
файлы и журналы %LOCALAPPDATA%\HRManager; содержимое secrets.json и pilot.env не
читается).
Тесты добавлены в существующие наборы: engine.tests.ps1 (+4), docker.tests.ps1
(+7), supervisor.tests.ps1 (+8), channel.tests.ps1 (+1), pilot-final.tests.ps1
(+1); в test-harness.ps1 — двойник внешнего процесса, сброс кэша выбора CLI и
уникальный мьютекс цикла на кейс. taskkill.exe добавлен в белый список внешних
команд (static.tests.ps1 и lint-engine.py) с обоснованием: .NET Framework
(Windows PowerShell 5.1) не умеет убивать дерево процессов — Process.Kill($true)
появился только в .NET Core.
Проверено в этой среде: infra/windows/tests/lint-engine.py — 37 файлов,
структурная проверка пройдена; git diff --check чисто. Поведенческие тесты
требуют Windows PowerShell 5.1 и выполняются в CI (windows-latest): здесь
PowerShell недоступен.
Co-authored-by: arena-agent <297053741+arena-agent@users.noreply.github.com>
This was referenced Oct 15, 2026
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
4 participants
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.
commit 4d3a76d updated the list of directories for discovering CLI plugins, adding
%ProgramFiles%\Docker\cli-pluginsfor system-wide plugins.For backward compatibility, the
%PROGRAMDATA%\Docker\cli-pluginswas kept, however, this location is no longer used, and not generally recommended for storing non-data content (such as CLI plugin binaries). From the ProgramData documentation:It also mentions "It can’t contain any serviceable components.", effectively meaning that these paths should not contain data that is managed (through updates etc.), making it a poor choice for installing "system wide" CLI plugins.
This patch removes the path from the list, given that this location is no longer used by Docker Desktop, and the CLI-plugin API is considered an internal implementation (since 459c608).
- What I did
- How I did it
- How to verify it
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)