search

StackStorm / ansible-st2

Ansible Roles and Playbooks to deploy StackStorm
https://galaxy.ansible.com/StackStorm/stackstorm/
Apache License 2.0
100 stars 75 forks source link

CI: Use Ansible Molecule for end-to-end testing #328

Closed mamercad closed 1 year ago

mamercad commented 1 year ago

Switch to Ansible Molecule for end-to-end testing in favor of Kitchen Ansible and Kitchen Docker (this project is currently without a maintainer and has many known issues). Molecule is the de facto answer to Ansible and testing. This pull request covers convergence (and idempotence) using both Python 3.6 and Python 3.8 against StackStorm stable and unstable. The reason why there are two different jobs (python36 and python38) is mainly to handle the different supported versions of Molecule. Lastly, this pull requests switches to completely running the end-to-end testing as non-root (which is nice since it validates that become: true works correctly); it appeared to me that the current end-to-end tests for Rocky Linux 8 and Focal used the root user (the same pattern for extending the existing Dockerfiles was used -- adding a non-root user named molecule). Here's an example running in my fork.

cognifloyd commented 1 year ago

I haven't reviewed yet, but I love getting rid of our dependence on ruby here. It feels like such a huge context switch when I have to touch something with ruby and the ruby-ist APIs of kitchen sheet working exclusively in python and Ansible for awhile.

Yes please. Let's use molecule to test this instead of kitchen.

mamercad commented 1 year ago

and it's falling on ChatOps tests due to rate-limiting.

Yeah, that's why I have it running serially, basically. I'll think on how to mitigate the rate-limiting even more.

arm4b commented 1 year ago

Yeah, that's why I have it running serially, basically. I'll think on how to mitigate the rate-limiting even more.

Please switch to the previous {repo}-{os} build matrix, there are several benefits behind that and it'll also help us with the rate-limiting naturally.

mamercad commented 1 year ago

Yeah, that's why I have it running serially, basically. I'll think on how to mitigate the rate-limiting even more.

Please switch to the previous {repo}-{os} build matrix, there are several benefits behind that and it'll also help us with the rate-limiting naturally.

Sure, do you care about testing both Python 3.6 and 3.8 locally (in CI) or do you want to just test 3.8?

arm4b commented 1 year ago

I see. We don't care which python version is installed on the client(user) side that runs Ansible. Ansible role repos usually don't test this.

From https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#node-requirement-summary "Managed node Python" is more important, but it has very wide py version support between py2.7-py3.11. So I wouldn't think about this too as Ansible core already does a good job maintaining compatibility.

From the build matrix, what's important is the Ansible Version compatibility with the roles that we have (https://github.com/StackStorm/ansible-st2/issues/242), OS (el7, U20, etc), and repo (stable/unstable).

mamercad commented 1 year ago

Closed in favor of #329.