You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Testing the Ansible collection should follow the CI practices we have in other integration repositories. There are clearly defined steps for testing the collection, but we're still relying on manually running the tests locally.
Use cases
CI testing parity with our other integrations
Test a wider set of Ansible & Python versions without maintaining multiple pyenvs & virtualenvs on developer machines
Improve confidence in changes and make it easier to review community contributions
Proposed solution
I suggest the approach taken by icinga-director collection to run their sanity and integration tests. They define multiple Python and Ansible-core versions and let the GitHub action take care of setup and teardown.
Integration tests present a different obstacle. We would need to test Connect against a 1Password testing environment to get useful results. I believe the Connect Helm-Chart or K8s operator run an integration suite with an account in a test environment. Perhaps we can do something similar?
Confirming the ansible-test sanity tests pass sounds like a good first step for this while we continue researching better integration test automations.
We'll want to split this issue into two:
add automated ansible-test sanity tests
add automated integration tests that spin up a Connect server and talk to a staging 1Password environment we control?
To avoid malicious actors we may want to restrict integration tests to only run after merging to main. That way we avoid drive-by PRs that could insert data into our staging 1Password environment
Summary
Testing the Ansible collection should follow the CI practices we have in other integration repositories. There are clearly defined steps for testing the collection, but we're still relying on manually running the tests locally.
Use cases
Proposed solution
I suggest the approach taken by icinga-director collection to run their
sanity
andintegration
tests. They define multiple Python and Ansible-core versions and let the GitHub action take care of setup and teardown.Integration tests present a different obstacle. We would need to test Connect against a 1Password testing environment to get useful results. I believe the Connect Helm-Chart or K8s operator run an integration suite with an account in a test environment. Perhaps we can do something similar?
Then running the Connect service should be doable with a GitHub Action service container.
Is there a workaround to accomplish this today?
We could continue testing manually, but that's not something we should encourage.
References & Prior Work
The LaunchDarkly Ansible Collection also runs tests with GitHub actions
T-Systems/MMS/ansible-collection-incinga-director
The text was updated successfully, but these errors were encountered: