Investigation of new Pipeline options - bcgov/common-service-showcase GitHub Wiki

GitHub Actions

• Direct integration with GitHub
  • Secrets are secure in repository settings
  • Environment protection rules can be set up per branch
    • Specify people or teams that must approve workflow runs in the environment (eg: can't run actions in prod unless a required reviewer allows it)
• yaml based
  • Files are stored within a top level .github folder in the repository

PROS:

• Direct integration with GitHub and GitHub events
• Environment protection rules to prevent unwanted deploys
• Only requires a single service account setup in OpenShift
• yaml is more code like than Tekton's
• Centralized pipeline - already using GitHub actions for other events

CONS:

• yaml files require a push to the environment to change, frustrating for testing new configs
• Fork based PR's will no longer function as they do not have access to the main repository secrets. These will have to be moved to branches

Tekton

• Integration with OpenShift via OpenShift Pipelines (https://github.com/openshift/pipelines-tutorial)
• yaml based
• Task and pipeline files are stored within OpenShift namespace using oc create or oc apply
• Requires TriggerTemplate, TriggerBinding, Trigger, & EventListener yaml files to be created which are used as hooks to GitHub to allow automation
• Expose EventListener service as route, manually configure WebHook within GitHub settings
• No apparent environment security, simply listens to the event and fires off the pipeline

PROS:

• Direct integration with OpenShift
• yaml files are easy to create/change via oc create or oc apply

CONS:

• Lacks environment deployment security 
• Many yaml files necessary for a single GitHub event

Discussion with some team members has resulted in a preference for utilizing GitHub Actions. Primarily due to the GitHub environment protection rules.

2 options for builds and deployments

Docker (https://github.com/docker)

• Basic flow for a build process
  • https://github.com/docker/setup-buildx-action
    • GitHub Action to set up Docker Buildx
  • https://github.com/docker/login-action
    • GitHub Action to login against a Docker registry
  • https://github.com/docker/metadata-action
    • GitHub Action to extract metadata (tags, labels) from Git reference and GitHub events for Docker
  • https://github.com/docker/build-push-action
    • GitHub Action to build and push Docker images with Buildx
• https://github.com/bcgov/pipeline-templates provides a workflow template for use with Docker
• https://github.com/bcgov/traction/tree/develop/.github could be used as a template for actual project implementation

RedHat (https://github.com/redhat-actions)

• https://cloud.redhat.com/blog/deploying-to-openshift-using-github-actions
• Basic flow for a build process
  • https://github.com/redhat-actions/oc-login
    • GitHub Action to log in to an OpenShift cluster and set up a Kubernetes context
  • https://github.com/redhat-actions/oc-installer
    • GitHub Action to install the OpenShift Client 'oc' into an action runner
  • https://github.com/redhat-actions/buildah-build
    • GitHub Action to use 'buildah' to build a container image.
  • https://github.com/redhat-actions/s2i-build (alternate to buildah, dont use both)
    • Github Action to build an OCI-compatible container image from source code.
    • Only runs on Linux. Can use GitHub's Ubuntu runners, or use https://github.com/docker/setup-buildx-action to setup a Docker daemon
  • https://github.com/redhat-actions/push-to-registry
    • GitHub Action to push a container image to an image registry
• Was unable to find any bcgov repositories utilizing the new redhat-actions
  • Repositories I found utilize the depracated redhat-developer/openShift-actions

GitHub also provides starter workflows (https://github.com/actions/starter-workflows)

• Can be automatically imported into your repository by going to https://github.com/bcgov/REPONAME/actions/new and selecting one

TODO:

• Look into Helm Charts (https://helm.sh/)