-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
salt-lint lints a phantom temporary file when run by another program #302
Comments
Hi @matthewsht! Thanks for your bug report. I'm fairly certain that v0.9.1 hasn't magically fixed this issue. But just to certain, could you please verify the issue also occurs on the latest release of salt-lint? Thanks in advance! |
I am also experiencing this using the latest version (0.9.2) leveraging the salt-lint Docker image. Relevant files:
When run from an interactive terminal:
Here is what I get when run within the GitLab CI Docker Runner:
My initial thought was to add a command line arg that suppresses this behavior for use in CI and other non-tty situations. Note that I am using a |
Describe the bug
I have a python program that runs multiple linters on our salt stack tree. When running salt-lint, salt-lint sees that it has no tty and assumes that stdin contains the file to be linted - it then opens a "phantom" temporary file and adds this to the filenames actually provided on the command line.
To Reproduce
Run a "wrapper" program around salt-lint (v0.8.0) and provide 1 or more salt (.sls) files on the command line. salt-lint will lint a phantom temporary file assuming that stdin contains a file.
The following is the output of my wrapper:
DEBUG: **********************************
DEBUG: ** Running a linter: salt-lint **
DEBUG: **********************************
DEBUG: salt-lint -v -R -r linters /Users/matthewsht/projects/saltstack/main/formulas/foobar/proxy.sls /Users/matthewsht/projects/saltstack/main/formulas/foobar/server.sls
['/opt/homebrew/bin/salt-lint', '-v', '-R', '-r', 'linters', '/Users/matthewsht/projects/saltstack/main/formulas/foobar/proxy.sls', '/Users/matthewsht/projects/saltstack/main/formulas/foobar/server.sls']
Examining /Users/matthewsht/projects/saltstack/main/formulas/foobar/server.sls of type sls
Examining /Users/matthewsht/projects/saltstack/main/formulas/foobar/proxy.sls of type sls
Examining /var/folders/kg/ylmhpwmn3hb2bdlwl84t6c989ztfk2/T/tmpk_jpw919.sls of type sls
Note that it provided two files to salt-lint: server.sls and proxy.sls: however salt-lint reports that it lints those two files
AND a third temp files (tmpk_ipw919.sls)
CODE:
This is from:
cli.py, line 30 testing for lack of a tty. I don't think thats a sufficient test. It should be lack of a tty AND no files submitted on the command line.
Adding some "hunter" debugging lines to cli.py, I get this output in a run:
hunter: Namespace(files=['/Users/matthewsht/projects/saltstack/main/formulas/foobar/proxy.sls', '/Users/matthewsht/projects/saltstack/main/formulas/foobar/server.sls'], listrules=False, rulesdir=['linters'], use_default_rules=True, tags=[], listtags=False, verbosity=1, skip_list=[], colored=False, exclude_paths=[], json=False, severity=False, c=None)
hunter: im not a tty
hunter: /var/folders/kg/ylmhpwmn3hb2bdlwl84t6c989ztfk2/T/tmparoytg2h.sls
Examining /Users/matthewsht/projects/saltstack/main/formulas/foobar/server.sls of type sls
Examining /var/folders/kg/ylmhpwmn3hb2bdlwl84t6c989ztfk2/T/tmparoytg2h.sls of type sls
Examining /Users/matthewsht/projects/saltstack/main/formulas/foobar/proxy.sls of type sls
we print the options and see the two provided sls files (proxy.sls and server.sls)
we then see we're not a tty
and invent a phantom sls file for the stdin.
The modified code that generated this output is:
options = parser.parse_args(args if args is not None else sys.argv[1:])
print('hunter:', options)
Expected behavior
salt-lint should lint ONLY lint files (and dirs) provided on the command line when any files/dirs are provided on the command line.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: