Super-linter: ansbile-lint not running if VALIDATE_ALL_CODEBASE or RUN_LOCAL is true

Created on 25 Jun 2020  路  11Comments  路  Source: github/super-linter

Describe the bug
Currently _ansible-lint_ will not run if VALIDATE_ALL_CODEBASE or RUN_LOCAL (which implies VALIDATE_ALL_CODEBASE) is set to true.

This is because the LIST_FILES array will be set to empty if the READ_ONLY_CHANGE_FLAG is set to 0:

https://github.com/github/super-linter/blob/master/lib/linter.sh#L464-L478

The only occurrences of READ_ONLY_CHANGE_FLAG=1 are within the BuildFileList() function which is called only if VALIDATE_ALL_CODEBASE is set to "false":

https://github.com/github/super-linter/blob/master/lib/linter.sh#L2270-L2275

Looks like a regression of this merged PR #34.

To Reproduce

$ docker run -e ACTIONS_RUNNER_DEBUG=true -e RUN_LOCAL=true -e ANSIBLE_DIRECTORY=playbooks -v <dir-with-ansible-code>:/tmp/lint github/super-linter | grep -i "ansible"
VALIDATE_ANSIBLE=true
ANSIBLE_DIRECTORY=/tmp/lint/playbooks
  -> Codebase does NOT have file:[.github/linters/.ansible-lint.yml], using Default rules at:[/action/lib/.automation/ ansible-lint.yml]
[ansible-lint]:
ansible-lint 4.2.0
Location:[/usr/bin/ansible-lint]

No output of this header https://github.com/github/super-linter/blob/master/lib/linter.sh#L390-L395 or any error messages https://github.com/github/super-linter/blob/master/lib/linter.sh#L554-L555.

Expected behavior
Ansible playbooks should also be linted on a local run/on VALIDATE_ALL_CODEBASE=true

bug

All 11 comments

Thanks for opening your first issue in the super-linter repo! :tada:

@kunzese Can you test against latest version?

@GaboFDC

Unfortunately, it does not work properly even with the new version. IMHO it's because of two reasons.

The first one is easy #436:

https://github.com/github/super-linter/blob/de92cc732e16c1b39541c0b39466e389eb726e83/lib/worker.sh#L607

This will never return any files, because globbing within quotes is not possible.

image

The second issue is, now that we have some sweet ansible yaml files within $LIST_FILES, the variable $READ_ONLY_CHANGE_FLAG is per default 0 so our $LIST_FILES with all the ansible yaml files is set to empty here:

https://github.com/github/super-linter/blob/de92cc732e16c1b39541c0b39466e389eb726e83/lib/worker.sh#L613-L626

The only times $READ_ONLY_CHANGE_FLAG is set to 1 is within the BuildFileList() function, which is only called if $VALIDATE_ALL_CODEBASE is set to "false".

https://github.com/github/super-linter/blob/15cd021893f5b687e054f6c7f5a5691f12e1c90d/lib/linter.sh#L938-L943

Also, consider that yaml is also a valid extension in this case (like you do for YAMLlint) :)

Also, consider that yaml is also a valid extension in this case (like you do for YAMLlint) :)

Yes of course. This was already addressed by #436.

Maybe the documentation is not clear enough, but ansible files should be under an /ansible directory to be linted. Or a directory defined by ANSIBLE_DIRECTORY

Unfortunately, setting ANSIBLE_DIRECTORY was not enough in my case. What I see is (stripped down irrelevant output):

Pulling image: github/super-linter:v3.4.0
Digest: sha256:e72979b95769cbc23a652a8f2f855e03df594768da452bdf264801191e952261
Status: Downloaded newer image for github/super-linter:v3.4.0
docker.io/github/super-linter:v3.4.0

.......

Gathering GitHub information...
NOTE: ENV VAR [RUN_LOCAL] has been set to:[true]
bypassing GitHub Actions variables...
Linting all files in mapped directory:[/workspace]

......

Gathering user validation information...
- Validating [ANSIBLE] files in code base...

......

--- DEBUG INFO ---
---------------------------------------------
.....
VALIDATE_ANSIBLE=true
...
ANSIBLE_DIRECTORY=/workspace/configuration/ansible
....

---------------------------------------------
  -> Codebase does NOT have file:[/workspace/.ansible-lint.yml], using Default rules at:[/action/lib/.automation/.ansible-lint.yml]

....

Successfully found binary in system
Location:[/usr/bin/ansible-lint]

Then, there's nothing else related to ansible-lint (and I used to run it as a standalone tool.

Same here. It all comes down to this code block where $LIST_FILES is emptied:

https://github.com/github/super-linter/blob/de92cc732e16c1b39541c0b39466e389eb726e83/lib/worker.sh#L613-L626

Yes can confirm this too. I set -x to debug it:

+ LintAnsibleFiles /tmp/lint/test/linters/.ansible-lint.yml
+ PRINT_ARRAY=()
+ PRINT_ARRAY+=("")
+ PRINT_ARRAY+=("----------------------------------------------")
+ PRINT_ARRAY+=("----------------------------------------------")
+ PRINT_ARRAY+=("Linting [Ansible] files...")
+ PRINT_ARRAY+=("----------------------------------------------")
+ PRINT_ARRAY+=("----------------------------------------------")
+ LINTER_NAME=ansible-lint
++ command -v ansible-lint
+ VALIDATE_INSTALL_CMD=/usr/bin/ansible-lint
+ ERROR_CODE=0
+ '[' 0 -ne 0 ']'
+ [[ false == \t\r\u\e ]]
+ LIST_FILES=()
+ SKIP_FLAG=0
+ '[' -d /tmp/lint/ansible/playbooks ']'
+ mapfile -t LIST_FILES
++ ls '/tmp/lint/ansible/playbooks/*.yaml' /tmp/lint/ansible/playbooks/datasources.yml
+ '[' 0 -eq 0 ']'
+ LIST_FILES=()
+ echo '- Skipping Ansible lint run as file(s) that were modified were read only...'
- Skipping Ansible lint run as file(s) that were modified were read only...
+ SKIP_FLAG=1
+ '[' 1 -eq 0 ']'
+ IsTAP
+ '[' '' == tap ']'
+ return 1
+ IsTAP
+ '[' '' == tap ']'
+ return 1

Shouldn't READ_ONLY_CHANGE_FLAG just be 0 if VALIDATE_ALL_CODEBASE=true?

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 馃 label or comment on the issue.

@admiralAwkbar can we reopen this? I tested against the latest version, and the issue is still there.

Why was #34 necessary?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bbaassssiiee picture bbaassssiiee  路  5Comments

patrick-compass picture patrick-compass  路  4Comments

tihuan picture tihuan  路  4Comments

ymd-h picture ymd-h  路  3Comments

dshevtsov picture dshevtsov  路  4Comments