Lindsey  Koepp

Lindsey Koepp


Get Started With CI/CD Using GitHub Actions

Welcome to the first part of a series of articles comparing CI/CD platforms. To help evaluate, compare and contrast the tools currently dominating the market, the goal will be to automate the deployment of a Flask application onto AWS Elastic Beanstalk. A new deployment will need to occur after every push to main branch, and during the series this same requirement will be implemented across a multitude of CI/CD tools.

First up, part 1 will focus on GitHub Actions, where the support for CI/CD was first announced in August 2019. I’ll document the steps taken along the way to achieve the goal with GitHub Actions, and there’s a write up of the positives and negatives in a conclusion at the end of this article.

Our application

The Flask application

Our Flask application is a simple “Hello World” example, and for the purposes of demonstrating running unit tests within the pipeline, we have included a test case as well.

AWS Elastic Beanstalk

Our Flask application is going to be deployed to AWS Elastic Beanstalk which is a service that automates the deployment and scaling of a web application. It takes in our source code and takes care of all the infrastructure configuration.

There’s a handy CLI for Elastic Beanstalk, and ultimately we’re going to automate the following commands into our pipeline. However, these are just for reference and you do not need to run these now.

$ eb init -p python-3.6 hello-world --region us-east-1
$ eb create hello-world-env

Introduction to GitHub Actions

Introduction to GitHub Actions…

  • An **event **will trigger a workflow.
  • A **workflow **contains one or more jobs.
  • A **job **is executed on a **runner **and will contain one or more steps.
  • A **step **will contain a single **action **or a series of inline commands.
  • The run can generate **artifacts **and use a cache.


A job _runner _is any machine with the GitHub Actions Runner Application installed — these machines can be GitHub-hosted or you can run your own.

GitHub-hosted runners are virtual machines — Linux (Ubuntu), Windows, and macOS — and are fully managed by GitHub and come with a lot of installed software. For example, the image for Ubuntu comes armed with multiple libraries, including the AWS CLI and Google SDK. As part of the free-tier, GitHub provides 2,000 minutes per month of its hosted runners.

The runner is defined in the workflow yaml with the runs-on property.

#devops #aws #github-actions #elastic-beanstalk #continuous-delivery

What is GEEK

Buddha Community

Get Started With CI/CD Using GitHub Actions
Derek  Champlin

Derek Champlin


Working with GitHub Actions

GitHub has become one of the most widely used Source Code Repository. Its Distributed Version Control System helps the developers for faster development and Integration of their code. Recently, it launched GitHub Actions in beta which enabled developers to create automated workflows to build, test, and deploy their source code on GitHub.

In this article, we will discuss about GitHub Actions and how it can be used to build an automated software development life-cycle workflow.

Below are the things we will discuss in this article:

About GitHub Actions

Using GitHub Actions, we can create custom workflows that will help to build, test, package, release or deploy the code without leaving the GitHub UI. It enables us to build Continuous integration and Continuous Deployment capabilities directly in our repository. Here are some important features about GitHub Actions.

**YAML based process: **The workflow is written in YAML. Hence it is easy to create, read and use the actions that make up the workflow.

**One Place for everything: **By using GitHub Actions, we can build and test the developed code directly in our repository. There is no need to worry about integrating the source code repository with other build and deployment tools. Everything can be done in one single place.

**Easy to integrate code: **Since enabling CI/CD directly in the repository is possible using workflows, creating merge requests(MRs), building, testing and integrating them become way more seamless.

#tech (re)view #build #cd #ci #ci-cd #github #github actions #gitlab-ci #gradle #java #test

Mikel  Okuneva

Mikel Okuneva


GitHub Demo Days - Using GitHub Actions for testing cloud native applications

What makes a project successful? For developers building cloud-native applications, successful projects thrive on transparent, consistent, and rigorous collaboration. That collaboration is one of the reasons that many open source projects, like Docker containers and Kubernetes, grow to become standards for how we build, deliver, and operate software. Our Open Source Guides and Introduction to innersourcing are great first steps to setting up and encouraging these best practices in your own projects.

However, a common challenge that application developers face is manually testing against inconsistent environments. Accurately testing Kubernetes applications can differ from one developer’s environment to another, and implementing a rigorous and consistent environment for end-to-end testing isn’t easy. It can also be very time consuming to spin up and down Kubernetes clusters. The inconsistencies between environments and the time required to spin up new Kubernetes clusters can negatively impact the speed and quality of cloud-native applications.

Building a transparent CI process

On GitHub, integration and testing becomes a little easier by combining GitHub Actions with open source tools. You can treat Actions as the native continuous integration and continuous delivery (CI/CD) tool for your project, and customize your Actions workflow to include automation and validation as next steps.

Since Actions can be triggered based on nearly any GitHub event, it’s also possible to build in accountability for updating tests and fixing bugs. For example, when a developer creates a pull request, Actions status checks can automatically block the merge if the test fails.

Here are a few more examples:

#engineering #enterprise #events #open source #actions #ci/cd #cloud native applications #cloud native architecture #devops #devops ci/cd #github actions #kubernetes #open source

Matt  Towne

Matt Towne


Serverless CI/CD on the AWS Cloud

CI/CD pipelines have long played a major role in speeding up the development and deployment of cloud-native apps. Cloud services like AWS lend themselves to more agile deployment through the services they offer as well as approaches such as Infrastructure as Code. There is no shortage of tools to help you manage your CI/CD pipeline as well.

While the majority of development teams have streamlined their pipelines to take full advantage of cloud-native features, there is still so much that can be done to refine CI/CD even further. The entire pipeline can now be built as code and managed either via Git as a single source of truth or by using visual tools to help guide the process.

The entire process can be fully automated. Even better, it can be made serverless, which allows the CI/CD pipeline to operate with immense efficiency. Git branches can even be utilized as a base for multiple pipelines. Thanks to the three tools from Amazon; AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy, serverless CI/CD on the AWS cloud is now easy to set up.

#aws #aws codebuild #aws codecommit #aws codedeploy #cd #cd pipeline #ci #ci/cd processes #ci/cd workflow #serverless

Nat  Kutch

Nat Kutch


Getting started with GitHub Actions

This article provides an introduction to GitHub Actions, which is GitHub’s native CI/CD and automation system.

The article first explains the basic concepts of GitHub Actions, such as workflows, jobs, and steps, and then presents several simple example workflows to get you started quickly. You can run all of these workflows in your own repository.


What is GitHub Actions?

GitHub Actions is a CI/CD and general automation system introduced by GitHub in 2018. It is integrated right into GitHub and enabled by default in every GitHub repository. GitHub Actions is completely free of charge.

With GitHub Actions, you can do similar things as with tools such as JenkinsTravis CICircle CIDrone CIBambooTeamCity, or AppVeyor. However, in contrast to these tools, GitHub Actions runs directly on GitHub, which means that your CI/CD and automation logic lives at the same place where your code lives. This has several advantages:

  • You don’t need to sign up for a separate CI/CD service (e.g. Travis CI, Circle CI, Drone CI, AppVeyor).
  • You don’t need to install and manage your own CI/CD service (e.g. Jenkins, Bamboo, TeamCity).
  • You don’t need to set up webhooks and access tokens for connecting your CI/CD service to GitHub — because GitHub Actions is already in GitHub!

All these advantages make it worthwhile to have a look at what GitHub Actions has to offer and how to use it. This is what this article is about!

Basic concepts

Let’s start with the basics. Here’s an overview of the most important concepts of GitHub Actions:

Image for post


Every GitHub repository can contain one or more workflows. Each workflow is defined in a separate YAML in the .github/workflows directory of the repo. Multiple workflows may run at the same time in parallel.


A workflow is triggered by one or more events. An event may be an internal GitHub event (such as a push, a release, or a pull request), a scheduled event (triggered at a specific time, like a cron job), or an arbitrary external event (triggered by a webhook call to the GitHub API).


A workflow consists of one or more jobs. A job contains a set of commands that will be run when the workflow is triggered (see steps below). By default, when a workflow is triggered, all of its jobs run in parallel. However, you can define dependencies between selected jobs to make them run sequentially.


Each job runs on a specific runner. A runner is a virtual machine hosted by GitHub with an operating system of your choice (Linux, macOS, or Windows). You can also use a self-hosted runner, in which case you have full control of the runner’s hardware and software.


A job consists of a sequence of steps. A step is either a shell command or an action (see actions below). All the steps of a job run sequentially on the runner associated with the job. By default, if a step fails, the subsequent steps of the job are skipped.


An action is a reusable unit of code which can be included as a step of a job. Actions can have inputs and outputs. You can create your own actions or use actions shared by the GitHub community. Shared actions are distributed on the GitHub Marketplace, and there exist several thousands of them.

Important references

Now that you know the basic concepts of GitHub Actions, let’s look at some documentation that you will use often when working with GitHub Actions:

  • Workflow syntax reference — contains the complete syntax specification for workflow files.
  • Events that trigger workflows — contains the complete list of events that you can use as the triggers for your workflows.
  • Software installed on GitHub-hosted runners — contains the complete list of tools that are installed on the various runners provided by GitHub.
  • Context and expression syntax — contains the specification of the so-called contexts that are available to every workflow run. The contexts include various contextual information such as the outputs of previous steps, secrets, and the payload of the event which triggered the workflow.
  • Webhook events and payloads — contains the specification of the payloads of the events which can trigger your workflows. The event payloads are contained in the context available to the workflows.
  • GitHub REST API reference — event payloads may contain one or more GitHub API objects. For example, the payload of the [pull_request]( event contains a pull request API object. The GitHub REST API reference contains the specifications of these API objects.

With these references, you are armed to get started with GitHub Actions!

In the following, you will create three example GitHub Actions workflows that you can try out in your own GitHub repository right away.

Example workflow 1 — Hello World!

This workflow does nothing but printing “Hello World!” to the standard output of the runner whenever a push to the repository occurs. Here’s the complete code for this workflow:

Let’s go through the definition of this workflow:

  • The name of the workflow is **hello-world** (defined by the [name]( field).
  • The workflow is triggered by the [push]( event (defined by the [on]( field).
  • The workflow contains a single job with an ID of **my-job** (this is also the name of the job).
  • The my-job job uses the **ubuntu-latest** GitHub-hosted runner (defined by the [runs-on]( field). At the time of this writing, the ubuntu-latest runner corresponds to Ubuntu 18.04 LTS.
  • The my-job job contains a single step named **my-step**. This step executes the shell command **echo "Hello World!"**.

Remember that you can look up all syntax elements for a workflow definition on the workflow syntax reference page in the GitHub Actions docs.

To add this workflow to your GitHub repository, first create a directory named .github/workflows in your repository (you can either use an existing GitHub repository or create a new one). Then save the above workflow file in this directory and push the change to GitHub.

Now, on GitHub, click on the Actions tab:

Image for post

On the left side, you should see your hello-world workflow. And since this workflow is triggered by pushes, and you just pushed to GitHub, the workflow has already been triggered and run. You can see this workflow run on the right side of the screen:

Image for post

From now on, whenever someone pushes to your GitHub repository, this workflow will be triggered and a new run will be added on the right side of the above screen.

To inspect the existing run of your workflow, click on it. This should take you to a new screen where you can see all the jobs of the workflow on the left side. Click on the my-job job and you should see all the steps of the job:

Image for post

You can see three steps there, Set up jobmy-step, and Complete job. The first and the last step have been automatically added by GitHub Actions. The my-step step is the step you defined in your workflow file.

#github-actions #ci-cd-pipeline #github #automation #devops

Juana  O'Keefe

Juana O'Keefe


A better logs experience with GitHub Actions

It’s now even easier to review logs from your GitHub Actions workflow runs. We’ve introduced several improvements to make the experience more performant, precise, and pleasing to use.

Why these changes matter

When we think about successful automation, we aim to spend the least amount of time looking at what’s automated, so we can focus our attention on what’s relevant. But sometimes things don’t go as planned, and we are required to review what happened. That debugging process can be frustrating; that’s why we’re introducing a series of changes that will improve both performance and user experience:

  • Simplified the layout structure
  • Introduced a single and faster virtualized scrolling
  • The search is now more responsive
  • Better ANSI, 8-bit, and 24-bit color support
  • URLs are now interactive
  • A new full-screen view mode
  • A refreshed UI that improves readability and overall interactions

#features #product #actions #ci/cd #github actions #github