This tooling works also for Items that are not yet part the EWC Community Hub, or even those which are hosted on private repositories. |
Items contributed to the community hub by the EWC are tested at regular intervals, to ensure functionality is preserved as the platform evolves. Said testing is automated for deployable Items of the Ansible Playbook Technology.
The automation ensured the following steps are always performed:
The same automation, with the same functionality mentioned above, is public as a Community Hub Item (see Ansible Playbook Test Deployment via GitHub Actions), and you, as an Item owner, can drag-and-drop it into your GitHub repository if you wish to make regular testing less of a chore and more of a standard and effortless part of your development process.
This page walks you through an example of how it all would look in practice, for a community-contributed Item, for example for the Pytroll Processing Community Hub Item with on-demand deployment to EUMETSAT site.
On-demand deployments imply manual interaction needed for triggering a test. However, the GitHub action can be customized to run on scheduled, or when a pull request is open, or even on every commit. See the official GitHub documentation for details. |
For our example, this is already done; the Item's source code is publicly available at https://github.com/nordsat/ewc-playbooks. |
Push your Item's source code (Ansible Playbook), or a mirror of it, to a GitHub repository.
OS_AUTH_URLOS_REGION_NAMEOS_APPLICATION_CREDENTIAL_IDOS_APPLICATION_CREDENTIAL_SECRETANSIBLE_SSH_PRIVATE_KEYinputs attribute with reasonable default values that meet the demand of your Item. In our example, the customized content can be found at https://github.com/nordsat/ewc-playbooks/blob/main/.github/workflows/test-eumetsat.yml. |
Commit the file to the main branch of your repository and move to the next section start triggering Item deployment tests.
If the test is successful you shall see are report directly in the UI, such as the following:
On the other hand, if the test deployment fails, you can check the report to understand if the problem is specific to the Item or the underlying VM provisioning, or dig deeper on run logs for details, or inspect the artifacts if available. This should allow you to pin point the reason of the failure without the need to run tests on your local environment.
Common issues we observe in practice include missing or misformatted SSH keys within the GitHub Action Secrets, incompatible Ansible-Python-Linux versions, or sporadic timeouts due to SSH connection taking longer than expected. |
In five steps and with a few clicks you now have a simple way to make tests not only easy to trigger but also to reproduce.