* 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>
ansible-documentation
This repository holds the ReStructuredText (RST) source, and other files, for user documentation related to the Ansible package and Ansible core.
Documentation for modules and plugins that are officially supported by the Ansible core engineering team is available in the
ansible/ansiblerepository.
Verifying your pull request
We welcome all contributions to Ansible community documentation. If you plan to submit a pull request with changes, you should verify your PR to ensure it conforms with style guidelines and can build successfully.
Setting up nox
This project includes a nox configuration to automate tests, checks, and other functions.
You can use these automated tests to help you verify changes before you submit a PR.
You can manually
set up your environment
if you prefer, but nox is more straightforward and create an isolated environment for you.
-
Install
noxusingpython3 -m pip install noxor your distribution's package manager. -
Execute
noxfrom the repository root with no arguments to run all docs checkers, Python code checkers, and a minimal HTML docs build. -
Alternatively, you can run only certain tasks as outlined in the following sections. Run
nox --listto view available sessions.
Building docs
The different Makefile targets used to build the documentation are outlined in
Building the documentation locally.
The nox configuration has a make session that creates a build environment and uses the Makefile to generate HTML.
-
Clone required parts of the
ansible/ansiblerepository.nox -s clone-coreSee Periodically cloning Ansible core for more information.
-
Build minimal Ansible Core docs.
nox -s make -
Run a specific Makefile target:
nox -s make -- clean htmlsingle rst=community/documentation_contributions.rst
Running automated tests
The nox configuration also contains session to run automated docs checkers.
-
Ensure there are no syntax errors in the reStructuredText source files.
nox -s "checkers(rstcheck)"See Running the final tests for more information.
-
Verify the docs build.
nox -s "checkers(docs-build)"This session cleans the generated docs after it runs. If you want to view the generated HTML in your browser, you should build the documentation locally. See Building the documentation locally for more information.
-
Lint, type check, and format Python scripts in this repository.
nox -s lint
Checking spelling
Use codespell to check for common spelling mistakes in the documentation source.
-
Check spelling.
nox -s spelling -
Correct any detected spelling errors.
nox -s spelling -- -w -
Select an option when
codespellsuggests more than one word as a correction.nox -s spelling -- -w -i 3
Dependency files
nox sessions use dependencies from requirements files in the tests/ directory.
Each session has a tests/{name}.in file with direct dependencies and a lock file in tests/{name}.txt that pins exact versions for both direct and transitive dependencies.
The lock files contain tested dependencies that are automatically updated on a weekly basis.
If you'd like to use untested dependencies, set PINNED=false as in the following example:
PINNED=false nox -s "checkers(docs-build)"
For more details about using unpinned and tested dependencies for doc builds, see Setting up your environment to build documentation locally.
Updating dependencies
Use the following nox session to update the dependency lock files in tests/.
nox -s pip-compile
To synchronize dependency lock files with base requirements files without changing transitive dependencies, use the --no-upgrade flag:
nox -s pip-compile -- --no-upgrade
This session requires Python 3.10.
If you do not have Python 3.10 installed, you can use root-less podman with a Python 3.10 image as follows:
podman run --rm --tty --volume "$(pwd):/mnt:z" --workdir /mnt docker.io/library/python:3.10 bash -c 'pip install nox ; nox -s pip-compile'