Open RobinR1 opened 4 days ago
Files identified in the description:
If these files are incorrect, please update the component name
section of the description or use the !component
bot command.
cc @AnderEnder @alxgu @andytom @commel @evrardjp @lrupp @sealor @toabctl click here for bot help
Additionally, I tried to mitigate this problem by adding:
- name: Install packages
community.general.zypper:
name:
- wget
- vim
register: zypper_output
failed_when: "'<message type=\"error\">' in zypper_output.stdout"
However, the zypper_output
variable does not contain a stdout
or stderr
:
"zypper_output": {
"changed": false,
"failed": false,
"name": [],
"rc": 0,
"state": "present",
"update_cache": false
}
I seem to have no way to catch the actual output of transactional-update like I see it when I manually execute the command on the target host.
Summary
When I try to install (a) package(s) using the zypper module on SLE Micro, transactional-update is used but even if the command fails, the task is marked OK and the play continues as if everything is alright.
It seems that transactional-update returns a 0 as returncode and Ansible then assumes everything is ok. Actual error messages of transactional-update are ignored.
Issue Type
Bug Report
Component Name
zypper
Ansible Version
Community.general Version
Configuration
OS / Environment
Steps to Reproduce
On target machine the packages wget and vim need to be installed. However the target is missing the repositories with those packages are in, so the task should fail as the packages to be installed are not to be found by the package manager.
Expected Results
I expected the task to fail with error
Actual Results
Task details:
And then the next task in the play is started assuming the required packages are installed.
Manually running the transactional-update command on the target machine gives this:
So return code is 0 but the output indicates that the packages are not installed and are in fact not found. I assume community.general.zypper assumes success when rc=0, but I think it should check the output of the command for
<message type="error">
instead of relying on the RC only.Code of Conduct