ci: ansible-lint requires dependencies to be installed [citest_skip]

[richm]

ansible-lint requires the dependencies in meta/collection-requirements.yml
and tests/collection-requirements.yml to be installed. tox-lsr 3.18.1
will ensure they are installed.

Refactor the tests somewhat so that the collection and test steps are separate.

Signed-off-by: Rich Megginson rmeggins@redhat.com

Summary by Sourcery

Update Ansible CI workflows to use newer tox-lsr and delegate linting and testing to tox-based collection and ansible-test environments across multiple Ansible and Python versions.

CI:

• Expand ansible-lint GitHub Actions workflow to run against multiple ansible-lint, ansible-core, and Python version combinations via a matrix strategy.
• Replace direct ansible-lint GitHub Action usage with tox-driven ansible-lint execution that installs required collection dependencies.
• Expand ansible-test GitHub Actions workflow to run sanity tests across a matrix of Ansible and Python versions using tox-managed environments.
• Bump tox-lsr version to 3.18.1 across CI workflows and adjust role-to-collection conversion to use the tox 'collection' environment.
• Keep the ansible-managed-var-comment and qemu-kvm integration test workflows aligned with the updated tox-lsr version.

Tests:

• Add a reusable task file to clear facts and run the linux-system-roles.trustee_client role with configurable failure handling for tests.

[sourcery-ai]

Reviewer's Guide

Updates CI workflows to use tox-lsr 3.18.1, refactors ansible-lint and ansible-test jobs to run via tox with explicit version matrices for ansible/ansible-lint/python, and adds a reusable Ansible task file to clear facts and run the linux-system-roles.trustee_client role with optional failure suppression.

Flow diagram for updated ansible-test and ansible-managed-var-comment tox-lsr usage

flowchart LR
  subgraph GitHubActions
    wf_ansible_test["Workflow ansible-test.yml"]
    wf_managed_var["Workflow ansible-managed-var-comment.yml"]
  end

  dev["Developer push / PR"] --> wf_ansible_test
  dev --> wf_managed_var

  subgraph SharedSteps["Shared CI pattern"]
    step_update_tools["Update pip, git"]
    step_install_tox_lsr["Install tox-lsr 3.18.1"]
  end

  wf_ansible_test --> step_update_tools
  wf_managed_var --> step_update_tools

  step_update_tools --> step_install_tox_lsr

  subgraph ansible_test_job["ansible-test job"]
    run_tox_ansible_test["Run tox-managed ansible-test envs"]
  end

  subgraph managed_var_job["ansible-managed-var-comment job"]
    run_ansible_plugin_scan["Run ansible-plugin-scan via tox-lsr"]
  end

  step_install_tox_lsr --> run_tox_ansible_test
  step_install_tox_lsr --> run_ansible_plugin_scan

Loading

File-Level Changes

Change	Details	Files
Pin CI to tox-lsr 3.18.1 across workflows.	Bumps tox-lsr installation from version 3.17.1 to 3.18.1 in all GitHub Actions workflows that use it Keeps the rest of the workflow steps intact aside from other refactors described separately	.github/workflows/ansible-lint.yml .github/workflows/ansible-test.yml .github/workflows/ansible-managed-var-comment.yml .github/workflows/qemu-kvm-integration-tests.yml
Refactor ansible-lint workflow to run via tox with a matrix of ansible-lint/ansible-core/Python versions.	Adds a job strategy matrix to test two ansible-lint/ansible-core/Python combinations aligned with Automation Hub and latest versions Sets up Python using actions/setup-python based on the matrix entry Replaces the manual collection conversion shell script with a simple tox -e collection invocation Replaces the ansible/ansible-lint GitHub Action with a tox-based ansible-lint-collection environment, parameterized via environment variables for ansible-lint and ansible-core versions and overriding basepython from the matrix	.github/workflows/ansible-lint.yml
Refactor ansible-test workflow to run ansible-test via tox with an ansible/Python version matrix.	Adds a job strategy matrix over multiple ansible-core versions (2-14 through 2-20 plus milestone) and corresponding Python versions Sets up Python using actions/setup-python based on the matrix entry Replaces direct lsr_ci_runtox invocation for collection conversion with tox -e collection Replaces the ansible-test GitHub Action with a tox-driven ansible-test-${version} environment, overriding basepython per matrix entry	.github/workflows/ansible-test.yml
Add reusable Ansible task file to clear facts and run the linux-system-roles.trustee_client role with optional failure handling.	Introduces a new task file that clears facts via meta: clear_facts before running the role Implements a block/rescue pattern to run the role with __sr_failed_when=false while safely ignoring failures, simulating include_role failed_when behavior Provides a default code path that runs the role normally when __sr_failed_when is not explicitly set to false	tests/tasks/run_role_with_clear_facts.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• In the ansible-lint and ansible-test workflows, the actions/setup-python step runs after installing tox/tox-lsr, which means those tools are installed into the runner’s default Python rather than the matrix Python; consider moving setup-python before the pip install so tox and plugins are consistently tied to the selected Python version.
• The tox -x ...basepython="python${{ matrix.versions.python }}" usage assumes executables like python3.12/python3.13 exist on PATH, which is not guaranteed by actions/setup-python (it only provides python/python3); it may be more robust to drop the basepython override and rely on the selected interpreter, or derive the correct executable name dynamically (e.g., via $(python -c ...)).

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the ansible-lint and ansible-test workflows, the `actions/setup-python` step runs after installing `tox`/`tox-lsr`, which means those tools are installed into the runner’s default Python rather than the matrix Python; consider moving `setup-python` before the pip install so tox and plugins are consistently tied to the selected Python version.
- The `tox -x ...basepython="python${{ matrix.versions.python }}"` usage assumes executables like `python3.12`/`python3.13` exist on PATH, which is not guaranteed by `actions/setup-python` (it only provides `python`/`python3`); it may be more robust to drop the `basepython` override and rely on the selected interpreter, or derive the correct executable name dynamically (e.g., via `$(python -c ...)`).

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}