As a contributor to the galasa open source project, I want builds to be in the open, and use github actions, so that I can see build logs, see built artifacts, benefit from integration with github actions, and all without using any resources within the secretive IBM firewall.
As the OMP summer mentor, I want to understand GH Actions better and have an example GH Actions workflow to show the mentee, to support the start of the mentorship.
Background
There are many benefits of moving our infrastructure to use github actions.
Builds will be immediately kicked off, no 2-minute delay for them to start.
build logs are available for ages
built artifacts can be made available within the build results
The 'automation' repository contains the Dockerfiles for the custom Docker images that are used by the other build pipelines. So before we move on to building any of the other components of Galasa, we need to recreate the automation build in GH Actions and make the Docker images it builds available in the GitHub Container Registry.
[x] gitcli (used for Tasks git-check-branch and get-commit which might not be needed for GH actions workflows but will see)
[x] openapi
[x] swagger
[x] openjdk11-ibm-gradle (used for testing galasactl runs submit local)
[x] argocd-cli (this won't be needed after we get rid of the development.galasa.dev maven registry sites, can remove argocd-cli image build after this)
Build tasks to ignore as they are not needed for GitHub Actions workflows are:
ghverify - No longer need GH verify to check if the PR opener is in code committers but will need a custom GH Action to do this
ghstatus - No longer need GH status to report back to the PR as this is built into GH Actions
ghmonitor - No longer need GH monitor to trigger builds as this is built into GH Actions
ghreceiver - No longer need GH receiver to send back 200 to webhook as webhook not needed
tkn - no longer need to chain pipelines together using the tkn cli
openjdk11-ibm - not used anymore
unzip - only used internally so moved to internal repo
zip - only used internally so moved to internal repo
Tasks
[x] Use GitHub actions to build each of the Docker images built in the 'automation' pipeline in the existing Tekton pipeline
[x] If a main build, push these Docker images in the GitHub Container Registry under the 'galasa-dev' organisation
[x] The GitHub actions workflow should be integrated with PRs as well as merges into the main branch, so we see the tekton and github actions build processes side by side
[x] Ignore the Task apply-galasa-properties for now do not recreate it, as it attempts to contact something behind the IBM firewall, so can't be done from GitHub actions
Story
As a contributor to the galasa open source project, I want builds to be in the open, and use github actions, so that I can see build logs, see built artifacts, benefit from integration with github actions, and all without using any resources within the secretive IBM firewall.
As the OMP summer mentor, I want to understand GH Actions better and have an example GH Actions workflow to show the mentee, to support the start of the mentorship.
Background
There are many benefits of moving our infrastructure to use github actions.
The 'automation' repository contains the Dockerfiles for the custom Docker images that are used by the other build pipelines. So before we move on to building any of the other components of Galasa, we need to recreate the automation build in GH Actions and make the Docker images it builds available in the GitHub Container Registry.
For reference, look at the existing Tekton pipelines for automation, but remove/adapt Tasks as appropriate for GitHub actions.
Build tasks to be recreated are:
galasactl runs submit local)Build tasks to ignore as they are not needed for GitHub Actions workflows are:
Tasks
apply-galasa-propertiesfor now do not recreate it, as it attempts to contact something behind the IBM firewall, so can't be done from GitHub actions