fbd828673d
* Fix distro fact handling for Flatcar The existence of the file /etc/flatcar/update.conf depends on bootstrap configuration typically provided by the user. For that reason this file is unsuitable for determining distro facts for Flatcar Container Linux. The distribution_release fact is meaningless in the case of Flatcar since Flatcar doesn't have named releases. The distribution_version fact, however, IS meaningful and should contain a number such as "3139.2.0". - Use /etc/os-release instead of /etc/flatcar/update.conf. - Drop the distribution_release fact. - Set the distribution_version fact. - Update distro test fixture for Flatcar - Generate the fixture using gen_distribution_version_testcase.py. - Override result.distribution and result.os_family manually as the generator script gives wrong values. - Use a recent Flatcar version. Signed-off-by: Johanan Liebermann <jliebermann@microsoft.com> |
2 years ago | |
|---|---|---|
| .. | ||
| azp | 3 years ago | |
| backport | ||
| build_library | 2 years ago | |
| tests | 2 years ago | |
| ticket_stubs | ||
| README.md | 2 years ago | |
| ansible-profile | ||
| build-ansible.py | ||
| create_deprecation_bug_reports.py | 3 years ago | |
| deprecated_issue_template.md | ||
| env-setup | 3 years ago | |
| env-setup.fish | ||
| fix_test_syntax.py | ||
| get_library.py | ||
| report.py | ||
| return_skeleton_generator.py | 2 years ago | |
| test-module | ||
| test-module.py | 3 years ago | |
| update-sanity-requirements.py | ||
README.md
'Hacking' directory tools
env-setup
The 'env-setup' script modifies your environment to allow you to run ansible from a git checkout using python >= 3.8.
First, set up your environment to run from the checkout:
$ source ./hacking/env-setup
You will need some basic prerequisites installed. If you do not already have them and do not wish to install them from your operating system package manager, you can install them from pip
$ easy_install pip # if pip is not already available
$ pip install -r requirements.txt
From there, follow ansible instructions on docs.ansible.com as normal.
test-module.py
'test-module.py' is a simple program that allows module developers (or testers) to run a module outside of the ansible program, locally, on the current machine.
Example:
$ ./hacking/test-module.py -m lib/ansible/modules/command.py -a "echo hi"
This is a good way to insert a breakpoint into a module, for instance.
For more complex arguments such as the following yaml:
parent:
child:
- item: first
val: foo
- item: second
val: boo
Use:
$ ./hacking/test-module.py -m module \
-a '{"parent": {"child": [{"item": "first", "val": "foo"}, {"item": "second", "val": "bar"}]}}'
return_skeleton_generator.py
return_skeleton_generator.py helps in generating the RETURNS section of a module. It takes JSON output of a module provided either as a file argument or via stdin.
fix_test_syntax.py
A script to assist in the conversion for tests using filter syntax to proper jinja test syntax. This script has been used to convert all of the Ansible integration tests to the correct format for the 2.5 release. There are a few limitations documented, and all changes made by this script should be evaluated for correctness before executing the modified playbooks.