There are 5 main stages that run on GitHub actions:

• Linting
• Test
• Packaging
• Benchmarking
• Release

The whole process should look like:

Checkout -> Linting -> Test -> Packaging -> Benchmark -> Release

• Full matrix compatibility should be triggered on a daily basis or manually.
• Subset matrix compatibility runs on branches, tags and PRs basis.
• Automated release in the CI gets triggered when a tag release is created.
• Pull Requests that are only affecting the docs files should not trigger any test or similar stages that are not required.
• Builds do not get triggered automatically for Pull Requests from contributors that are not Elasticians when need to access to any GitHub Secrets.

Python agent supports compatibility to different python versions and frameworks, those are defined in:

• frameworks for all the PRs.
• frameworks for the daily builds.
• Python versions for all the daily builds.
• Python versions for all the *nix builds.
• Python versions for all the windows builds.
• Exclude list for the above entries.

Once a PR has been opened then there are two different ways you can trigger builds in the CI:

1. Commit based
2. UI based, any Elasticians can force a build through the GitHub UI

Every time there is a merge to main or any release branches the whole workflow will compile and test every entry in the compatibility matrix for Linux and Windows.

This process has been fully automated and it gets triggered when a tag release has been created. The tag release follows the naming convention: v.<major>.<minor>.<patch>, where <major>, <minor> and <patch> are numbers as defined here

There is a GitHub workflow in charge to populate what the workflow run in terms of jobs and steps. Those details can be seen in here (NOTE: only available for Elasticians).