Maxwell G 91ebd253b4 [stable-2.14] Backport pr_labeler changes (#1918)
* pr_labeler: improve create_boilerplate_comment logging

(cherry picked from commit 5730ba9a01)

* pr_labeler: add --force-process-closed flag

(cherry picked from commit 44ffe0f210)

* 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 commit d2e6625e8b)

* 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 commit dddfd7eb55)

* 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 commit 746662c255)

* pr_labeler: improve porting_guide_changes template wording

Co-authored-by: Sandra McCann <samccann@redhat.com>
(cherry picked from commit 95ece7e9d6)

* 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 commit 763815d1ad)

* 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 commit 466b1fdc43)

* 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 commit 7138e42716)
(cherry picked from commit 1cf9f7917b)

---------

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2024-09-20 10:49:10 +01:00
2023-10-22 02:03:50 +00:00

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/ansible repository.

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 nox using python3 -m pip install nox or your distribution's package manager.

  • Execute nox from 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 --list to 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/ansible repository.

    nox -s clone-core
    

    See 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 codespell suggests 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'
Description
No description provided
Readme 234 MiB
Languages
Python 94.8%
Shell 3.5%
Jinja 1.7%