-
Notifications
You must be signed in to change notification settings - Fork 677
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
var-spacing: False-positive in name #2209
Comments
Similiar situation with 6.3.0.
Line 20 is the first line of this task: - name: "sysctl net.ipv6.conf.*.accept_ra"
ansible.builtin.command:
cmd: "sysctl -n net.ipv6.conf.{{ interface }}.accept_ra"
loop: "{{ ansible_interfaces | select('match', '^(eth|en)') | list }}"
loop_control:
loop_var: interface
register: "net_ipv6_conf_interface_accept_ra"
changed_when: false |
I also stumbled into this:
The relevant parts of the task file are:
My current workarround is:
But I would like to see this newly introduced false positive fixed. ;-) |
Another example:
Referring to: cas_shared_instance_config: >-
{{ grp_all_cas_instances_shared_config[cas_instance.split("|").0 | trim] }}
|
Another example of a false positive where this rule triggers for me (on - name: Save list of all configurable interfaces
ansible.builtin.set_fact:
_configurable_interfaces: >
{{ _available_interfaces.meta.results | json_query("[?!mac_address || mac_address != '00:00:00:00:00:00'].name") | list | sort }} and - name: Assert that DHCP interfaces do not have an IP or gateway set
ansible.builtin.assert:
that:
- item.subnet is not defined
- item.gateway is not defined
fail_msg: 'Interface is set to use DHCP but also has a static IP or static gateway configured!'
quiet: true
loop: >
{{ interfaces | json_query("[?!mode || mode == 'dhcp']") }}
loop_control:
label: '{{ item.name }}' |
That bug is valid but it will not be easy to fix because current implementation uses regex, so i quite limited. If someone can make a patch and use jinja2 parsing to check it, it would be awesome. |
I had the same problem here in the following example: - name: Execute command
shell: "set -o pipefail && egrep -R 'stringA|stringB' /apps/smartclick/log/* | grep {{ input.user_id }}"
register: result
become: true
changed_when: "result.stdout is defined and \
result.stdout | length > 0 and \
'link' in result.stdout"
failed_when:
- result.stderr is defined
- result.stderr | length > 0 As a workaround I inserted the "# noqa var-spacing" comment: - name: Execute command
shell: "set -o pipefail && egrep -R 'stringA|stringB' /apps/smartclick/log/* | grep {{ input.user_id }}" # noqa var-spacing
register: result
become: true
changed_when: "result.stdout is defined and \
result.stdout | length > 0 and \
'link' in result.stdout"
failed_when:
- result.stderr is defined
- result.stderr | length > 0 |
Yet another false positive: (slightly modified to remove sensitive information) - name: setup nginx for nextcloud
ansible.builtin.include_role:
name: nginx
tasks_from: vhost
vars:
server_name: nextcloud.example.com
proxy_type: http
vhost_conf: |
# https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html#nextcloud-in-the-webroot-of-nginx
root /usr/share/webapps/nextcloud;
index index.php index.html;
location ~ \.php(?:$|/) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
include fastcgi.conf;
fastcgi_param PATH_INFO $fastcgi_path_info;
# Avoid sending the security headers twice
# https://github.com/nextcloud/server/blob/v23.0.1/lib/private/legacy/OC_Response.php#L97
fastcgi_param modHeadersAvailable true;
fastcgi_pass unix:{{ php.fpm_sockdir }}/nextcloud.sock;
}
# Image paths do not contain index.php regardless of `front_controller_active`
# https://github.com/nextcloud/server/blob/v23.0.1/lib/private/URLGenerator.php#L179
location / {
try_files $uri /index.php$request_uri;
} @ssbarnea Apparently there are many false positives. How about disabling the var-spacing rule by default (ex: mark as |
We will not disable this rule but we have plans to fix in the following weeks. For the moment you can either use noqa to disable the rule in your config. To give some insights why not doing this: the rule is not new and the number of false positive is relatively small to the positive ones. We already discussed about this issue last week and we identified a way to use jinja2 parser instead of a regular expression. |
Got it. Thanks for clarifying the plan. I'm willing to test it if there is a patch. |
* Add in ansible shell commands to patch storageclasses * Add "changed_when" to command * Current bug with ansible-lint giving false-positives: ansible/ansible-lint#2209 * Utilise ansible kubernetes.core.k8s_json_patch * Try removing noqa var-spacing
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
This change rewrites jinja2 rule to make it use jinaja lex parser and avoid use of regexes for parsing, as they cause too many false positives. Fixes: ansible#2301 ansible#2285 ansible#2241 ansible#2209 ansible#2208 ansible#2120
Summary
I am getting:
with ansible-lint 6.3
Issue Type
Ansible and Ansible Lint details
OS / ENVIRONMENT
MacOS
STEPS TO REPRODUCE
See https://github.com/sblask/dotfiles/runs/6824840729?check_suite_focus=true
You can also just run ansible-lint on https://github.com/sblask/dotfiles/blob/main/ansible/includes/zipped_executable.yml to get the following:
Desired Behavior
There should be no warning.
Actual Behavior
There is a warning even though the spacing is fine and even though https://github.com/sblask/dotfiles/blob/main/ansible/includes/zipped_executable.yml has the same pattern in the name 7 times, I only get a warning for 2
The text was updated successfully, but these errors were encountered: