Dolt's GitHub Actions

This doc will provide context for the types of Workflows we use in this repository. This doc is not a comprehensive GitHub Actions tutorial. To familiarize yourself with GitHub Actions concepts and the terminology, please see the documentation.

Dolt uses GitHub Actions Workflows in four primary ways:

• To run continuous integration tests on pull requests and pushes to main
• To release and publish new Dolt assets
• To deploy various benchmarking jobs to contexts other than GitHub Actions (like in a Kubernetes cluster, for example).
• To handle misc. repository_dispatch events triggered by external clients.

Continuous Integration Workflows

Workflows prefixed with ci- are run on pull requests to main, though some run on pushes to main (after a pull request is merged). These workflows are synchronous and don't trigger any other workflows to run.

Dolt Release Workflows

Workflows prefixed with cd- are used for releasing Dolt. Some of these workflows are asynchronous, meaning that they only perform part of a task before triggering the next part of a task to run in a different workflow, sometimes in other GitHub repositories, using repository_dispatch events.

Benchmarking Workflows

Benchmarking workflows are used as an interface for deploying benchmarking jobs to one of our Kubernetes Clusters. Workflows that deploy Kubernetes Jobs are prefixed with k8s- and can only be triggered with repository_dispatch events. Notice that benchmarking workflows, like workflows/performance-benchmarks-email-report.yaml for example, trigger these events using the peter-evans/[email protected] Action.

These Kubernetes Jobs do not run on GitHub Actions Hosted Runners, so the workflow logs do not contain any information about the deployed Kubernetes Job or any errors it might have encountered. The workflow logs can only tell you if a Job was created successfully or not. To investigate an error or issue with a Job in our Kubernetes Cluster, see the debugging guide here.

Misc. Repository Dispatch Workflows

Some workflows perform single, common tasks and are triggered by repository_dispatch events. These include the workflows/email-report.yaml that emails the results of performance benchmarks to the team, or the workflows/pull-report.yaml that posts those same results to an open pull request. Workflows like these are triggered by external clients.