* play_context, compensate for existing plugins
some connection plugins are not fully using the correct configuration,
but this was previously hidden from them as play_context was providing
the info instead, now play_context provides the 'correct' info, but hitting
these bad configurations.
* ansible-galaxy collection install|verify:
- Support verifying the origin of the MANIFEST.json when the Galaxy server has provided signatures.
- Allow supplemental signatures to use during verification on the CLI/requirements file.
* ansible-galaxy collection install:
- Support disabling signature verification. This silences the warning provided by ansible-galaxy if the Galaxy server provided signatures it cannot use because no keyring is configured.
- Store Galaxy server metadata alongside installed collections for provenance. This is used by 'ansible-galaxy collection verify --offline'.
* Add unit tests for method that gets signatures from a Galaxy server
* Add integration tests for user-provided signature sources
- Test CLI option combinations
- Test installing collections with valid/invalid signature sources
- Test disabling GPG verification when installing collections
- Test verifying collections with valid/invalid signature sources
* Make signature verification advisory-by-default if signatures are provided by the Galaxy server
- Make the default keyring None
- Warn if the keyring is None but the Galaxy server provided signatures
- Error if the keyring is None but the user supplied signatures
- Error if the keyring is not None but is invalid
* changelog
* add ansible-galaxy user documentation for new options
Co-authored-by: Matt Martz <matt@sivel.net>
Co-authored-by: Sviatoslav Sydorenko <wk.cvs.github@sydorenko.org.ua>
Co-authored-by: Martin Krizek <martin.krizek@gmail.com>
Co-authored-by: Sandra McCann <samccann@redhat.com>
Co-authored-by: Andy Mott <amott@redhat.com>
Co-authored-by: John R Barker <john@johnrbarker.com>
* Return rc=0 on success.
Error handling in playbooks generally expects `rc` to be set to 0 when a module has not failed. Playbook authors should not have to check for the existence of `rc` first.
* Use single definition and added changelog
* Fix up tests with new return value
Co-authored-by: Jordan Borean <jborean93@gmail.com>
* add DebianStrategy tests
* ensure hostname can be changed by using become
* use Systemd strat for debian and Base for generic.
* add test to ensure all strategies are available
Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
avoid polluting vars with incorrect settings
simplify variables and templars
- variables, original, only updated with final results, reset are copies of this
- tempvars used for preliminary templating
- cvars used for connection/shell/become plugins, delegation aware
- vars_copy ignore tempvars updates and use connection plugin to get
finalized version per loop item/delegation, also used to store temp results
till we are ready to update 'variables'
- fine tune nolog just cause we are here
- also fix inventory_hostname_short for IP addresses
git module now uses env vars exclusively
- updated docs to clarify usage
- now env vars append instead of overwrite to allow existing custom setups to keep working
fixes#38104, #64673, #64674
- added note for hostkeychecking more securely
fixes#69846
- keep script cause old versions still choke on env
- env var cannot hold more than 'command' for older versions
- all ssh_opts in one place
ssh plugin, use 'correct' information source in all cases
* still fallback to pc
* added inventory to new test
* undef var can still show as parser error on pc
now task_exectuer has a more accurate error handling
Installation of `gcc` is failing while trying to install dependencies:
```
[MIRROR] libxcrypt-devel-4.4.18-3.el9.x86_64.rpm: Interrupted by header callback: Server reports Content-Length: 32565 but expected size is: 33101
```
* removed those made obsolete by bot
* tried to rephrase to be more informative and require less updates in the future
Co-authored-by: Sandra McCann <samccann@redhat.com>
Co-authored-by: John R Barker <john@johnrbarker.com>
Co-authored-by: Alicia Cozine <879121+acozine@users.noreply.github.com>
Azure Pipelines only supports publishing a single code coverage file.
This limits us to reporting on either Python or PowerShell.
It also prevents us from reporting coverage per test command without further aggregation.
Most of our users are only aware of the reports published to codecov.io.
Brian Coca