Modules and plugins can only have one integration test target associated with them.
When there is a conflict between alias(es) and/or the target name, only one target will trigger on changes to the module or plugin.
* Clean up FILE_COMMON_ARGUMENTS.
* postgresql_pg_hba doesn't declare the backup option.
* uri doesn't declare the remote_src option.
* Add documentation.
* maven_artifact seems to use directory_mode, which it doesn't declare.
* Update changelogs/fragments/66389-file-common-arguments.yml
Update docs/docsite/rst/porting_guides/porting_guide_2.10.rst
ci_complete
Co-Authored-By: Jill R <4121322+jillr@users.noreply.github.com>
The test fails in the CI with a timeout of vmware_guest_tools_wait. It's
still unclear if this comes from:
- the ESXi environment
- the VM configuration, e.g: the amount of the RAM
- the ISO image itself
Ideally, we should have a light VM with the vmware-tools.
I didn't properly update the commit message via github UI. Revert, to
open a new PR.
This reverts commit 2794142eb3.
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This looks to be causing issues for our new ansible.netcommon
collection. Revert for now, until we can properly address.
This reverts commit 53c7f8cbde.
* Refactor coverage file enumeration.
* Relocate sanitize_filename function.
* Support sets when writing JSON files.
* Generalize setting of info_stderr mode.
* Split out coverage path checking.
* Split out collection regex logic.
* Improve sanitize_filename type hints and docs.
* Clean up coverage erase command.
* Fix docs and type hints for initialize_coverage.
* Update type hints on CoverageConfig.
* Split out logic for finding modules.
* Split out arc enumeration.
* Split out powershell coverage enumeration.
* Raise verbosity level of empty coverage warnings.
* Add code coverage target analysis to ansible-test.
The edgeos_config module had a list of commands to filter out to avoid
load failures. This list had a single regular expression which caught
commands that attempted to set pre-encrypted passwords. This behavior is
undesirable for a few reasons.
* It's poorly documented. The documentation makes cryptic mention of a
return value that some commands might be filtered out, but offers no
explanation as to what they are or why.
* It's hard-coded. There's no way for the user to change or disable this
functionality, rendering the commands caught by that expression
completely unusable with the edgeos_config module.
* The obvious workaround is unsafe. The filter catches passwords that
are already encrypted, but is perfectly fine letting the user set
plain-text passwords. EdgeOS will encrypt them upon commit, but this
module encourages unsafe handling of secrets up to that point.
* It's a security vulnerability if the user doesn't know about this
behavior. While the module will warn if commands are filtered, the
user won't know what got filtered out until after the fact, and may
easily miss that warning if they are not vigilant. For something as
sensitive as setting a password, it's not hard to imagine naive use of
this module resulting in incorrect credentials being deployed.
* It provides no discernible benefit. Using the module without filtering
does not result in load failures. If those commands are indeed harmful
for some reason on (old?) versions of EdgeOS, it should be incumbent
upon the user to be scrupulous in what commands they issue, rather
than the module maintaining a blacklist of possible ways the user
might misuse their own system.
