Repository navigation
Galaxy incorrectly reports deps already installed #5137
Description
Activity
- added a commit that references this issue
on Aug 5, 2026 I hit the same failure and traced it to a PATH mismatch between the two steps of the action. Details below in case they help, plus a workaround that avoids the quoting hack.
What the pinned versions have in common
Your
requirements.ymlpinsansible.posix 2.2.2,community.general 13.2.0, andcommunity.docker 5.2.1. Those are exactly the versions bundled in theansible14.2.0 package. Mine wascommunity.general 13.2.0alone, with the same result.Where the bundled copy comes from
actions/runner-imagesprovisions ansible withpipx install ansible-corefollowed bypipx inject ansible-core ansible(images/ubuntu/scripts/build/install-pipx-packages.sh), so an ubuntu-latest runner carries the fullansiblepackage and its bundled collections in the pipx venv, withansible-galaxyon PATH via/opt/pipx_bin.Why the action's own ansible-galaxy is not the one that runs
The install step runs
uv tool install --with-executables-from ansible-core "ansible-lint[lock] @ ...", and the log reports:Installed 1 executable: ansible-lintOnly
ansible-lintis exposed, soansible-galaxy install -r <requirements_file>in the next step resolves to the runner's pipx-injected ansible. That resolver sees the bundled collections, decides the exact pins are satisfied, and printsNothing to dowithout writing anything into~/.ansible/collections.ansible-lintthen runs inside the uv tool environment, which has ansible-core only, and cannot resolve the modules.I should be clear about which parts are observed and which are inferred. Observed, and reproduced on two runs of the same commit with
ansible/ansible-lint@v26.4.0(ansible-lint 26.4.0, ansible-core 2.21.2):- A pin matching a bundled version produces
Nothing to doon a fresh runner and the collection is never installed. - Changing the pin to a non-bundled version (
community.general 13.1.0) makes the same step download and install normally, and the lint run passes. - A clean local environment with the same ansible-core 2.21.2 installs
13.2.0without complaint, so this is not a resolver or Galaxy metadata problem.
Inferred: that the binary running in the requirements step is specifically the pipx one. That is consistent with the
Installed 1 executableline and with how the runner image provisions ansible, but I did not printwhich ansible-galaxyto confirm it directly.Workaround without modifying the input string
Rather than passing
--forcethroughrequirements_file, dropping the input and installing in an explicit step works and keeps the input's contract intact:- name: Install collection dependencies run: ansible-galaxy collection install -r playbooks/collections/requirements.yml --force - name: Run ansible-lint uses: ansible/ansible-lint@v26.4.0 with: args: playbooks/
That run installs
community.general:13.2.0into/home/runner/.ansible/collections/...and lint passes.Possible fixes upstream
Adding
--forceto the action'sansible-galaxy installinvocation is the smallest change. Installing the collections with the same ansible-core that later runs ansible-lint would address the underlying mismatch, since the two steps currently disagree about which environment defines "installed".- A pin matching a bundled version produces
- added 4 commits that reference this issue
on Aug 11, 2026 - added a commit that references this issue
on Aug 12, 2026 - added a commit that references this issue
on Sep 27, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Cannot find duplicate matching issue
Version: v26.6.0
Summary
When running GitHub action, galaxy incorrectly reports deps already installed.
Issue Type
OS / ENVIRONMENT
OS: Ubuntu latest (24.04) GHA hosted runner.
STEPS TO REPRODUCE
Fresh ansible playbooks repository with the following structure:
A requirements.yml with the following content:
The GitHub actions workflow
Desired Behavior
A compliant repository in subdirectory
ansiblepasses with zero warnings or errors.Actual Behavior
Galaxy install step reports zero dependencies to install.
Following ansible lint run reports missing dependencies:
The linter errors are a symptom of what I suspect is an issue with the Galaxy install step.
To add further validation to my claim, the following workaround / hack resolves the issue:
The GitHub actions workflow