* pr_labeler: improve create_boilerplate_comment logging (cherry picked from commit5730ba9a01) * pr_labeler: add --force-process-closed flag (cherry picked from commit44ffe0f210) * pr_labeler: add warning for porting_guides changes This adds a warning message when PRs are created that edit porting_guides by someone outside of the Release Management WG. These files are automatically generated during the ansible release process and should not be modified. Fixes: https://github.com/ansible/ansible-documentation/issues/503 (cherry picked from commitd2e6625e8b) * pr_labeler: use @release-management-wg team for porting_guide check Instead of hardcoding the list of release managers, we can use the Github API to retrieve the members of the `@ansible/release-management-wg` team. (cherry picked from commitdddfd7eb55) * pr_labeler: exempt bots from porting_guide check For example, patchback is not a release manager, but we still want it to backport Porting Guide PRs. (cherry picked from commit746662c255) * pr_labeler: improve porting_guide_changes template wording Co-authored-by: Sandra McCann <samccann@redhat.com> (cherry picked from commit95ece7e9d6) * pr_labeler: refactor new_contributor_welcome code (#990) * pr_labeler: add GlobalArgs.full_repo property * pr_labeler: refactor new_contributor_welcome code As of https://github.com/ansible/ansible-documentation/issues/69, the pr_labeler responds with a welcome message when an issue or PR is opened by a new contributor. It turns out this never actually worked properly. The previous method that relied on Github's `author_association` flag did not work with the app token that the pr_labeler uses. This refactors the code to figure out whether a user is a new contributor by searching the list of issues and PRs. Fixes: https://github.com/ansible/ansible-documentation/issues/204 * pr_labeler: address potential race condition (cherry picked from commit763815d1ad) * Bump actions/setup-python from 4 to 5 (#966) Bumps [actions/setup-python](https://github.com/actions/setup-python) from 4 to 5. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](https://github.com/actions/setup-python/compare/v4...v5) --- updated-dependencies: - dependency-name: actions/setup-python dependency-type: direct:production update-type: version-update:semver-major ... (cherry picked from commit466b1fdc43) * pr_labeler: re-architect triager script (#1882) This commit reorganizes the issue/PR triager script and updates the workflow to run more efficiently. - Make the script a proper Python package instead of an unwieldy single file - Use locked dependencies and UV to decrease workflow runtime to under 10 seconds. (cherry picked from commit7138e42716) (cherry picked from commit1cf9f7917b) --------- Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
'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.