AnsibleByExample

Ansible Execution Environment Example: Publishing an EE Definition to GitHub

Advanced
2024-01-014By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

Red Hat Ansible Automation Platform 2.7's Automation Portal ships a visual Execution Environment (EE) Builder — a 4-step wizard that produces an EE definition without hand-editing YAML. This example focuses on Step 3, Destination and Build, where you name the definition and push it to a GitHub repository. Shown at Red Hat Tech Day Netherlands 2026 in Bunnik, this step is where the wizard's output leaves the portal and becomes a version-controlled artifact.

The generated execution-environment.yml that the wizard publishes looks like this:

---
version: 3

images:
  base_image:
    name: registry.redhat.io/ansible-automation-platform-25/ee-minimal-rhel9:latest

dependencies:
  galaxy:
    collections:
      - name: redhat.rhel_system_roles
        version: "1.20.5"

additional_build_steps:
  append_final: []

And the portal metadata captured in wizard Step 3 (Destination and Build), summarized as a reference:

---
ee_definition:
  name: "network-config-ee"
  description: "EE for network configuration playbooks using RHEL system roles"
  tags:
    - network
    - rhel9

destination:
  provider: github
  authentication: required
  repository: "https://github.com/example-org/network-config-ee"

build:
  trigger_on_publish: true

What this does and why

Step 1 of the wizard picks the base image — here, the recommended Red Hat Ansible Minimal EE (Ansible Core 2.18 on RHEL 9). Step 2, Configuration, adds collections via a picker that searches both Private Automation Hub (rh-certified content) and GitHub; the example above adds redhat.rhel_system_roles at version 1.20.5, matching what was demonstrated live. Advanced Configuration in that same step is where you'd layer in extra Python requirements, system packages, or custom build steps if the defaults don't cover your dependencies.

Step 3, Destination and Build, is the handoff point. You give the EE definition a name, a description, and tags — these are the fields the portal's EE catalog later displays and lets you search on, alongside owner and star/edit/delete actions. You then authenticate against GitHub and pick (or create) the target repository. The wizard commits the definition file to that repo, so the EE's source of truth lives in Git rather than only inside the portal's database — useful for review workflows, diffing changes, and reproducing builds outside the UI.

The trigger_on_publish: true toggle is the other half of this step: check it and the portal kicks off an image build immediately after the push, so you don't have to return to the catalog and start the build manually. Leave it unchecked if you want to publish now and build later — for example, if a teammate still needs to review the pull request the publish action created.

Step 4, Review, is the last checkpoint before any build actually runs, giving you a final look at the base image, collections, and destination settings together.

Notes

  • GitHub authentication in Step 3 is a real prerequisite — the wizard won't let you pick a repository until the connection is authorized.
  • Name and tags set here are what populates the searchable EE definition catalog later, so treat them like you would any other metadata you'll need to filter on across dozens of EEs.
  • Triggering the build on publish still runs through the same underlying build pipeline as a manual build — it's a scheduling convenience, not a different execution path.
  • redhat.rhel_system_roles v1.20.5 in the example above reflects the exact version shown during the Tech Day walkthrough; pin whatever version your environment actually needs.

Step 3 is the point where a point-and-click EE definition becomes a Git-tracked, buildable artifact — get the name, tags, and destination right here and the rest of your EE lifecycle (review, rebuild, promote) stays traceable.

References

All Tutorials