Tool Chain for Build Pipeline - GitHub Actions vs. Jenkins

Acronym

sig-devops-build-pipeline

Belongs to

SIG DevOps

Responsible

tzaika und hbuhl

History

(v1)   2021-01-13 - created initially

(v2)   2021-01-15 - added responsible person, but it can be only temporary; First explanation of "Why is there need for such a decision?"

(v3)   2021-01-15 - viable options added; deadline updated; changed title

(v4)   2021-02-09 - added TODOs and cleaned up.

(v5)   2021-02-09 - added new TODOs and some new information

(v6)   2021-02-12 - Refined evaluation and did TODOs

Why is there need for such a decision?

The application needs to be delivered to a server in order to be available. This delivery process will be automated and will continuously deploy the newest version of the project to the server. Each new version of application will be created as a docker image. Then it should be transferred to server and run as a docker container. UID is providing a remote server.

The decision Testing Automation with GitHub Actions was a short-term solution to enable testing automation earlier in the project.

Additional sources for better understanding the background

• CI/CD
• Continuous integration
• Continuous delivery
• Jenkins (software)
• GitHub Actions - Features
• GitHub Actions - Documentation
• GitHub Actions - Workflow Syntax
• Jenkins website
• Run GitHub Actions locally
• GitHub vs Jenkins - Blog on bitsrc
• GitHub vs Jenkins - Blog on medium

Viable Options

• Realize build pipeline using GitHub Actions
  • build
  • test
  • transfer jar (deploy) to the server
  • run the application
• Realize build pipeline using Jenkins (Execute the whole pipeline on the server with Jenkins)

Alternatives not seriously considered

• Execute some portion (compile + test) on GitHub and the rest (build + deploy) on the server

How is this decision evaluated?

• The solution should fit well into existing solutions
• It must be free (except the remote server)
• It should be resistant to changes happening in the project
• The open source nature of the project should not be put in jeopardy
• Multiple build jobs concurrently
• Solution must be able to listen to GitHub push event (full automation)

Resolution Details

Wiki

Unique features of using GitHub Actions:

• No need to worry about infrastructure and scaling/running it
• GitHub Actions can be run locally and in the cloud
• No installation/setup required (!)
• No extra plugins that need to be kept up to date
• GitHub Actions workflow visualization (job graph)
• There is a GitHub Action for every GitHub event
• Configuration files can be managed in GitHub; no need to manually copy to server in order to build
• GitHub as host for repo as well as build pipeline (centralized)
• Easy access to GitHub API (Jenkins might require token?)
• GitHub Marketplace (over 4000 actions published since GitHub introduced CI tools)

Unique features of Jenkins on the remote server:

• Independent of GitHub (Microsoft)
• Plugins are available for cashing support

Our decision is GitHub Actions

Reasons for the resolution

The initial setup of Jenkins do not fit the project at the moment and could lead to a time shortage (This decision could be re-evaluated in the future depending on where the project stands). The open source nature of GitHub Actions, and the nature of the project make GitHub Actions the far more superior solution.