| Mostly the driver doesn't matter; for the CI stuff you basically want to carry out "actions" on "events". As a concrete example you might wish to run your test cases when a new pull-request is opened, or an existing one is updated. The way that glue/integration works is going to be somewhat specific to the setup you're already using. That's why you'll find Github Actions being documented for Github, Jenkins for self-hosted repositories, etc. Broadly speaking it doesn't matter which "thing" you use to drive your CI, the key is that it works reliably and that the stuff which is executed is inside your repository. That way: * Developers can run it manually if they wish (e.g. "make test") * The CI system can be swapped out in the future, if you need to. As a concrete example once I migrated a company's repositories from bitbucket, using their pipelines, to (self-hosted) Github Enterprise. Because the pipeline just said "Run .git/tests.sh" porting the glue was trivial. I even published a github action for those using github, so that you can launch your project-specific tests in a portable and simple fashion: https://github.com/skx/github-action-tester |