ansible-lint
ansible-lint copied to clipboard
github action fails to download ansible-lint-requirements.txt, assumes .git dir exists in working directory
Summary
Issue Type
- Bug Report
OS / ENVIRONMENT
github actions
STEPS TO REPRODUCE
ansible-lint workflow:
- uses: ansible/[email protected]
with:
working_directory: ansible
Desired Behavior
Requirements file is downloaded to a path that exists and used successfully.
Actual Behavior
It seems that the action assumes there will be a .git directory, which isn't necessarily the case if using anything other than the repository root as the working directory (such as shown in the example above).
2023-12-11T02:01:18.5977779Z ##[group]Run wget --output-document=.git/ansible-lint-requirements.txt https://raw.githubusercontent.com/ansible/ansible-lint/$GH_ACTION_REF/.config/requirements-lock.txt
2023-12-11T02:01:18.5980286Z [36;1mwget --output-document=.git/ansible-lint-requirements.txt https://raw.githubusercontent.com/ansible/ansible-lint/$GH_ACTION_REF/.config/requirements-lock.txt[0m
2023-12-11T02:01:18.6021388Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2023-12-11T02:01:18.6022054Z env:
2023-12-11T02:01:18.6022395Z GH_ACTION_REF: v6.22.1
2023-12-11T02:01:18.6022818Z ##[endgroup]
2023-12-11T02:01:18.6176869Z .git/ansible-lint-requirements.txt: No such file or directory
2023-12-11T02:01:18.6198199Z ##[error]Process completed with exit code 1.
Look at our action usage example https://github.com/ansible/ansible-lint --- you MUST clone before calling the action or it will fail.
I am doing so. Here's the full workflow (private repo so no link, sorry):
---
name: Ansible Lint
on:
push:
paths: ['ansible/**']
workflow_dispatch:
jobs:
lint:
name: Ansible Lint
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Run ansible-lint
uses: ansible/[email protected]
with:
working_directory: ansible
As described in the initial issue, because I am setting the working directory to a subdirectory of the cloned repository, there is no .git directory.
As a result, wget --output-document=.git/ansible-lint-requirements.txt <url> fails, since it expects .git to exist.
This is also an issue if you're using self-hosted runners with git < 2.18. When this is detected any version of the standard checkout action will use the GitHub REST API instead of real git which means there's no .git directory.
Is it fair to paraphrase this bug as: ansible-lint is broken for monorepo users? I.e. those who put automation/ansible scripts in a subdirectory, and happen to use anything outside of ansible.builtins, can't really put ansible-lint in CI? For now my workaround is to skip a good portion of our .yml files under exclude_paths in .ansible-lint. Open to suggestions on better workaround.
I think that's a separate issue from this @ajfabbri
@jhg03a can you elaborate? IIUC this bug is the thing keeping us from being able to use ansible-lint on files with requirements (outside of ansible.builtins) in our monorepo CI. Since our ansible scripts are in a subdirectory, and .git directory is only at the root level, lint fails to find external requirements, causing an un-skippable lint failure.
The action is not supposed to work on sparse checkouts. You need a .git folder. I will closing this as a wont fix because I do not think there is anything we can do.
If we decide to dump the requirements lock file in to the current directory, we might broke the codebase because we would create a file that is not tracked or ignored by git.
Use of .git folder was seen as an acceptable alternative in this case, as it would always be ignored by git.
It should also be noted that the security model used by GHA does not allow us to write files to other random locations on disk outside current project directory.
Still, if someone finds a better solution for this, we will be more than happy to consider it.
Thanks for looking @ssbarnea. The description here is a bit confusing, but it does not require a sparse checkout to reproduce. The linked PR has a fix and the description includes the GH action I'm using to test it. Hope this helps.
The fix for this in #4103 was reverted by #4213. It's now broken again. This issue should be reopened.