All repositories use Travis CI through the file .travis.yml to orchestrate the execute of CI jobs. We would like to move away from Travis CI and instead build repositories using the GitHub Actions framework, which are also a set of yaml files that are installed into .github/workflows. Documentation for GitHub Actions can be found at https://docs.github.com/en/free-pro-team@latest/actions.

The workflows for repositories should be defined so that the build process is executed both for pull requests and any commits that are pushed. Additionally, the workflows should build Debezium using JDK8. We have an additional workflow, see .github/workflows/jdk-outreach-workflow.yml that is designed to also build and test the connectors against JDK 14 and 15 daily.

The Debezium main repository contains a number of modules. It would be good if the GitHub Actions were designed in a way so that by using filters, the jobs can be selectively activated based on the files changed as a part of the pull request or the commit. For example:

• If only changes exist for /documentation, the workflow won't need to build and run tests for any connector.
• If only changes exist for /debezium-connector-XXXXXXX, only build and run tests for that specific connector only.
• If changes exist for any other module in the main repository, a full build of all connectors & modules is required.

With the Incubator repository, I would suggest we follow the same pattern as the main repository if we can; trying to aim that builds only perform a specific connector build if the changes in the pull request or commit target a specific connector only. If the changes include files elsewhere such as the main incubator repository's pom.xml, then all connectors should be built & tested.

Lastly, it would be super great if a commit made to any files in the Debezium core repository under /documentation could trigger a remote invocation of the GitHub Action to build the Debezium website repository. We looked into this when GitHub Actions were first introduced but at the time that wasn't possible. It is possible that's been added somehow and if so, we'd certainly like to take advantage of being able to remotely trigger a website build under this specific scenario only.