Introduction

GitHub Actions provides a powerful and flexible platform for automating workflows directly within your GitHub repository. One common use case is automating the testing of collections in Ansible, ensuring that each component functions as expected. This article will guide you through the setup of a GitHub Actions workflow for testing Ansible collections using the .github/test.yml configuration.

Understanding the Configuration

Let’s break down the structure of the .github/test.yml file:

name: GHA for foo.bar

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

on:
  pull_request:
    branches: [main]
  workflow_dispatch:
  schedule:
    - cron: '0 0 * * *'
  • name: Describes the name of the GitHub Actions workflow.

  • concurrency: Specifies concurrency settings, ensuring that workflows do not interfere with each other. The group attribute combines workflows under the same conditions, and cancel-in-progress cancels any currently running workflow if a new one is triggered.

  • on: Defines the events that trigger the workflow. In this case, the workflow is triggered on pull requests targeting the main branch, manually using workflow_dispatch, and on a daily schedule.

Join 50+ hours of courses in our exclusive community

Now, let’s look at the job definitions:

jobs:
  ansible-lint:
    uses: ansible-network/github_actions/.github/workflows/ansible-lint.yml@main
  changelog:
    uses: ansible-network/github_actions/.github/workflows/changelog.yml@main
  integration:
    uses: ansible-network/github_actions/.github/workflows/integration_simple.yml@main
  sanity:
    uses: ansible-network/github_actions/.github/workflows/sanity.yml@main
  unit-galaxy:
    uses: ansible-network/github_actions/.github/workflows/unit_galaxy.yml@main
  • jobs: Lists the individual jobs that will be executed. Each job is defined separately and utilizes existing workflows from the ansible-network/github_actions repository.

    • ansible-lint, changelog, integration, sanity, and unit-galaxy are examples of jobs that can be run independently.

Next is the all_green job:

  all_green:
    if: ${{ always() && (github.event_name != 'schedule') }}
    needs:
      - changelog
      - integration
      - sanity
      - unit-galaxy
    runs-on: ubuntu-latest
    steps:
      - run: >-
          python -c "assert set([
          '${{ needs.changelog.result }}',
          '${{ needs.integration.result }}',
          '${{ needs.sanity.result }}',
          '${{ needs.unit-galaxy.result }}'
          ]) == {'success'}"          
  • all_green: This job runs only if certain conditions are met. It runs on the latest version of Ubuntu and depends on the successful completion of the changelog, integration, sanity, and unit-galaxy jobs.

  • steps: Specifies the steps to be executed within the job. In this case, it runs a Python script to assert that the results of the dependent jobs are all ‘success’. If any job fails, the assertion will fail, and the workflow will not proceed.

Conclusion

By using the GitHub Actions workflow defined in the .github/test.yml file, you can automate the testing of Ansible collections, ensuring that changes to your repository are thoroughly validated. This setup promotes efficiency, consistency, and reliability in your development process. Feel free to customize the workflow to fit the specific needs of your project.

Subscribe to the YouTube channel, Medium, and Website, X (formerly Twitter) to not miss the next episode of the Ansible Pilot.

Academy

Learn the Ansible automation technology with some real-life examples in my Udemy 300+ Lessons Video Course.

BUY the Complete Udemy 300+ Lessons Video Course

My book Ansible By Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps

BUY the Complete PDF BOOK to easily Copy and Paste the 250+ Ansible code

Want to keep this project going? Please donate

Patreon Buy me a Pizza