You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Introduction

This tooling is works also Items that are not yet part the EWC Community Hub, or which are even 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. This testing is automated for deployable Items of the Ansible Playbook Technology. 

At a glance, the automation offers:

  • VM provisioned
  • Item installation on the new VM
  • Cleanup after deployment (on success or failure)
  • Summary report generation
  • Artifacts upload  (for auditing and issue tracing, contains run logs, package versions and other useful runtime information)

The same automation used internally by the EWC, with the same functionality, 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 said drag-and-drop operation would look in practice for a community-contributed Item, for example Pytroll Processing, 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.

Prerequisites

GitHub source code hosting

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.

Step-by-Step Setup

  1. Get OpenStack API credentials (see How to request OpenStack Application Credentials section of the EWC documentation)
  2. Extract the following attributes from your app credentials and store them within your repository's GitHub secrets (see Creating secrets for a repository section of the GitHub documentation):
    • OS_AUTH_URL
    • OS_REGION_NAME
    • OS_APPLICATION_CREDENTIAL_ID
    • OS_APPLICATION_CREDENTIAL_SECRET
  1. Create an SSH keypair (see Generating a new SSH key section of the GitHub documentation )
  2. Add you SSH public key to OpenStack (see Import SSH Key section of the EWC documentation).
  3. Once more, update your repository's GitHub secrets to include the value of the private ssh key as: 
    • ANSIBLE_SSH_PRIVATE_KEY
  4. Create a GitHub workflow configuration file, copy-paste the example snippet shown in the Usage section of the Item's documentation, and add an inputs  attribute with reasonable default values that meet the demand of your Item. 


Commit the file to the main branch of your repository and move to the next section start triggering Item deployment tests.

Triggering Tests via GitHub Actions UI

  1. Browse to your GitHub Repository's Actions tab, and select the new workflow for the list on the left side panel

  2. Click on Run workflow, override the defaults or provide values for the empty inputs if necessary (optional, useful if you want to change the VM Image, or Ansible version to test on, etc.)
  3. Scroll to the bottom of the screen an confirm by clicking on Run workflow
  4. Await for the run to complete to gain access to the report summary.

 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 includemissing or misformatted SSH key within the GitHub Action Secrets, incompatible Ansible-Python-Linux versions, or sporadic timeouts due to VM ssh connection taking longer than expected.


Conclusion

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.

Related Articles

  • No labels