I’m a regular user of GitHub. Not too long ago I identified GitHub also has a construct-in CI/CD workflow remedy termed GitHub Steps. Curious about how this would operate I made the decision to try out it out. I had beforehand make a Jenkins Pipeline to complete several static and dynamic software protection assessments on a Java undertaking and decided to try and rebuild this pipeline working with GitHub Actions. This website put up describes my very first activities and impressions. You can locate my workflow and take a look at code in this article.
No external surroundings needed
A person of the speedy added benefits I discovered was that the Jenkins Pipeline needs a Jenkins set up to execute it. GitHub Actions operate on their own in your GitHub repository so no exterior atmosphere is expected. Do intellect that GitHub Steps have some restrictions. If you want to use them extensively, you will finally possibly need to have to pay back.
Built-in with GitHub
GitHub Actions are of training course certain to GitHub and combine very well with repository performance. Mainly because of this, you would possibly only use them if your source code is in GitHub. There are really a whole lot of solutions to have a workflow triggered. For case in point on a press or pull ask for, on a timetable or manually. Since GitHub Actions are built-in with GitHub and joined to your account, you will get automated mails when a workflow succeeds or fails.
If you want to combine Jenkins with GitHub, the conversation is ordinarily carried out by means of webhooks. This involves you to expose your Jenkins ecosystem in a way GitHub can achieve it. This can be difficult to do securely (may have to have you to punch holes in your firewall or use a polling mechanism). Also if you want to be informed of the results of a establish by e-mail, you want to outline mail server configurations/credentials in Jenkins. For GitHub Steps this is not expected.
My Jenkins / SonarQube environment offer reporting abilities. At the close of a establish you can come across a variety of experiences back in Jenkins and issues are developed in SonarQube. In SonarQube you can define high quality gates to let the create are unsuccessful or not.
Utilizing GitHub Steps, this works in a different way. Letting a construct are unsuccessful is anything to explicitly script rather of configured employing a GUI. At the stop of a create you can export artifacts. These can include reports but you have to have to open up them on your own. A further selection is to publish them to GitHub Web pages (see here). Therefore no ‘out of the box’ capability to do reporting for GitHub Actions.
GitHub has so-referred to as “Issues” but these appear not to be meant to sign-up personal results of the distinctive static code investigation instruments. They get the job done much better to just sign-up a one situation for a unsuccessful make. Of system, there are GitHub Steps offered for that.
To be truthful, I did not dive into how to build custom pipeline ways in my Jenkins ecosystem. I observed you can code some Groovy and combine that with a Pipeline but it would likely require pretty a time financial commitment to get hold of the expected awareness to get a little something performing. For GitHub Steps, generating your very own Actions is pretty easy and described here. You generate a repository for your Action, a Dockerfile and a yaml describing the inputs and outputs of the Motion. Subsequent you can specifically use it in your GitHub workflows. As the Dutch would say ‘een variety kan de was doen’ (basically: ‘a youngster can do laundry’. It is a indicating which suggests: ‘it’s child’s play’ or ‘piece of cake’)
Challenges rebuilding a Jenkins Pipeline
I experienced created a simple Jenkins Pipeline to compile Java code, carry out static code analysis, generate a container, deploy it to Docker Hub, scan the container working with Anchore Engine, complete an automated penetration take a look at applying OWASP ZAP, feed the success to SonarQube and look at a High quality Gate.
The principal worries I experienced with rebuilding the pipeline were being operating with containers through the create procedure and how to deal with caching.
Commencing and stopping containers
The most important problems I had when setting up the Jenkins Pipeline was that Jenkins was jogging inside of a container and I needed to spawn new containers for Anchore, ZAP and my software. Ultimately I made a decision to use docker-compose to start out anything upfront and do a manual restart of my software just after the container image in Docker Hub was current. This obstacle is related when working Jenkins on K8s.
Using GitHub Actions, the atmosphere is different. You pick a so-named runner for the develop. This can be a self-hosted environment but can also be GitHub hosted. GitHub offers various flavors of runners. In essence, this gives you for illustration a Linux VM on which you can operate stuff, commence and cease containers and a lot more or much less do whatever you want to perform your build. The Jenkins challenge of setting up and stopping containers from within a container is just not there!
For GitHub Steps, you must be conscious there are several approaches to offer with containers. You can define service containers which will begin when your workflow begins. You can also execute sure steps in a container you specify with the ‘uses’ search term. When these do not suffice, you can simply call docker right your self from a run command or by contacting an exterior script. I chose the previous alternative in my workflow. See my script here for beginning the OWASP ZAP scan in a container.
To cut down establish time, you can cache artifacts this kind of as Maven dependencies but also of container illustrations or photos. For the container images you can assume of photographs cached by Google Jib or photos cached by the Docker daemon. I experimented with caching visuals from the Docker daemon but that enhanced my build time. Most most likely since of how the cache labored. Each impression which was saved in the cache and afterwards restored, included all underlying layers. In all probability sure layers are component of numerous visuals so they are saved several moments. It appeared downloading only the expected layers was more rapidly than caching them and restoring them on a upcoming develop. If you are having said that far more concerned about community bandwidth than storage, you can of program even now apply this.
For my job, caching the Maven and Jib artifacts caused my build time to go from 7m 29s to 4m 45s so this appeared quite efficient. Almost certainly because artifacts are only downloaded after (no doubles) and there are several small artifacts which all have to have building a connection to a Maven repository. Applying a saved repository was quicker than downloading in this scenario.
Setting setting variables
Placing ecosystem variables in GitHub Steps was not so a great deal of a obstacle but in my viewpoint, the approach I employed felt a little bit peculiar. For pushing an picture from my Maven make to Docker Hub, I necessary Docker Hub qualifications. In all probability I ought to have made use of a Docker Hub accessibility token alternatively for extra safety but I didn’t.
I desired to register my Docker Hub credentials in GitHub as techniques. You can do this by registering repository strategies and refer to them in your GitHub Actions workflow utilizing a thing like: $ secrets.DOCKER_USERNAME .
From these secrets and techniques, I created surroundings variables. I did this like
methods: - name: Set surroundings variables run: | echo "DOCKER_USERNAME=$ secrets.DOCKER_USERNAME " >> $GITHUB_ENV echo "DOCKER_PASSWORD=$ tricks.DOCKER_PASSWORD " >> $GITHUB_ENV
I could also have specified the ecosystem at the step degree or at the workflow level employing the env search phrase like
env: # Set surroundings variables DOCKER_USERNAME: $ strategies.DOCKER_USERNAME
DOCKER_PASSWORD: $ techniques.DOCKER_PASSWORD
The to start with selection is incredibly versatile since you can use any bash assertion to fill variables. The 2nd option nevertheless is much more readable.
Finding started with GitHub Actions
Producing GitHub Steps is rather uncomplicated. You create a file termed .github/workflows/major.yml in your GitHub repository. You can use a supplied starters from GitHub specific to a language or create 1 from scratch for yourself.
When you have developed these kinds of a file, you can go to the Actions tab in GitHub following you have logged in
You can in my circumstance open up the CI workflow and operate it manually (I decide on to do it manually but as described, you can use other triggers). When undertaking a develop manually, you can determine inputs but I did not use that functionality.
When you open up a make, you can look at logging and created artifacts (beneath summary). In my case in point I released the exam studies as artifacts and pushed my created container to Docker Hub. I was not so a great deal intrigued in the created JAR file.
Thoughts that I didn’t want to set up any natural environment on my have but just used the freely obtainable GitHub Actions performance.
You can search the pipeline here.
identify: CI # Controls when the motion will run. on: # Makes it possible for you to operate this workflow manually from the Actions tab workflow_dispatch: # A workflow run is created up of just one or extra work that can run sequentially or in parallel jobs: # This workflow incorporates a one career named "establish" construct: # The style of runner that the occupation will run on runs-on: ubuntu-20.04 # Ways signify a sequence of responsibilities that will be executed as section of the position steps: - identify: Set surroundings variables operate: | echo "DOCKER_USERNAME=$ strategies.DOCKER_USERNAME " >> $GITHUB_ENV echo "DOCKER_PASSWORD=$ insider secrets.DOCKER_PASSWORD " >> $GITHUB_ENV # Checks-out your repository less than $GITHUB_WORKSPACE, so your career can entry it - name: Checkout sources uses: actions/checkout@v2 # Runs a single command making use of the runners shell - name: Setup Java 11 takes advantage of: actions/setup-java@v1 with: java-model: 11 #- identify: Cache Docker photographs # takes advantage of: satackey/action-docker-layer-caching@v0..11 # # Dismiss the failure of a phase and stay away from terminating the job. # go on-on-mistake: real - title: Cache Maven offers and Google Jib cache works by using: actions/cache@v2 with: route: | ~/.m2 ~/.cache/google-cloud-instruments-java/jib vital: $ runner.os -m2-$ hashFiles('**/pom.xml') restore-keys: $ runner.os -m2 - title: Static checks operate: mvn --batch-mode --update-snapshots dependency-look at:test pmd:pmd pmd:cpd spotbugs:spotbugs - name: Publish picture to Docker Hub run: mvn --batch-manner --update-snapshots compile jib:build - title: Anchore scan utilizes: anchore/scan-action@v1 with: graphic-reference: "docker.io/maartensmeets/spring-boot-demo" are unsuccessful-build: legitimate - identify: Start off services run: | docker network generate zap docker run --pull normally --identify spring-boot-demo --community zap -d -p 8080:8080 docker.io/maartensmeets/spring-boot-demo - name: OWASP ZAP scan operate: | # make file runnable, may well not be needed chmod +x "$GITHUB_WORKSPACE/.github/zap_cli_scan.sh" # run script "$GITHUB_WORKSPACE/.github/zap_cli_scan.sh" mv owaspreport.html target - name: 'Publish Exam Report' if: normally() utilizes: steps/upload-artifact@v2 with: title: 'test-reports' path: | goal/*.html concentrate on/website/ ./anchore-studies/
As you can see, the workflow is rather readable, besides maybe the OWASP ZAP part. The different actions have by now been described typically before. It was a disgrace I did will need to fall back again a couple of periods on working direct shell instructions and scripts as a substitute of wholly relying on re-usable GitHub Actions. Increasing that could be a little something for the long term.
It is pleasant you can create a badge to use in your GitHub README file indicating the status of the build.
GitHub Steps are out of the box CI/CD workflow functionality which you can use (with some limits) when you have a cost-free GitHub account. Simply because it is out of the box operation, you are not needed to setup your personal CI/CD natural environment to reach the identical.
It runs within GitHub and is rather nicely built-in with for example repository gatherings and secrets functionality. There are a great deal of GitHub Steps by now available and making/making use of your possess is a piece of cake. The workflows can be triggered in numerous strategies and you can fall back on guide scripting if needed. The delivered runner pictures contain a Docker installation so functioning with containers also operates properly (which can be complicated when your own CI/CD setting runs inside of a container). You can even use your individual runner in for illustration a various cloud to get improved functionality and additional resources for the runner if you will need it. To summarize, GitHub Actions are powerful, versatile and perfectly integrated with other GitHub supplied features.
GitHub Actions are great when you have your project in GitHub and never want to set up your possess CI/CD atmosphere. When you are for instance utilizing a private repository exterior of GitHub, utilizing GitHub Actions is not the clear choice.
I was disappointed by the out of the box reporting abilities. I could crank out reviews, nonetheless I could not publish them everywhere simply without introducing supplemental dependencies. Scripting the technology of GitHub Concerns also did not appear like it was the way to go to clear up this. I could use GitHub Internet pages, nonetheless, a website link would not be immediately accessible from the make itself (like I was employed to in Jenkins) and the logic on how to deal with studies from diverse builds/branches and accumulating the stories in a solitary available webpage, is something to produce for your self (or use a specific company). A great deal of the performance of a resource like SonarQube was also a little something I missed, these types of as wonderful grained challenge administration and the means to determine quality gates