Setup CI/CD on GitHub Actions for Multiple Environments Deployment

Automate, customize, and execute your software development workflows right in your repository with GitHub Actions. You can discover, create, and share actions to perform any job you’d like, including CI/CD, and combine actions in a completely customized workflow.

Prepare Docker Hub repository

Create a repository in your Docker hub for this GitHub repository Docker image

Create workflow in GitHub Actions

Go to the Actions page of your GitHub repository, and create a whatever workflow you’d like.

Write workflow and define env

Use a branch dev to trigger the CI. Define the build args “PROFILE” or any other argument in the workflow and you will use it as the profile to run SpringBoot. Be noted that you should define the Docker Hub account and repository here.

on:
  push:
    branches:
      - dev

jobs:
  hello_world_job:
    runs-on: ubuntu-latest
    name: A job to build and push docker
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Login to DockerHub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKER_HUB_USER }}
          password: ${{ secrets.DOCKER_HUB_PASS }}

      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          file: ./Dockerfile
          pull: true
          push: true
          cache-from: type=registry,ref=hustakin/hello-world-docker-action:latest
          cache-to: type=inline
          tags: hustakin/hello-world-docker-action:latest
          build-args: PROFILE=nectar,ARG2=test

Create secrets for the Github repository

You should create the secrets DOCKER_HUB_USER (Docker Hub account) and DOCKER_HUB_PASS (Docker Hub password) as per you defined in the above workflow.

Create Dockerfile

Create a Dockerfile in the root folder of your project. You can specify the build argument in the Dockerfile and read it. You will see the Github Action workflow triggered after you push the code to the dev branch.

See GitHub Actions workflow logs

You will see the build argument PROFILE could be get in your Dockerfile.

Write Dockerfile for SpringBoot

The jar file of your SpringBoot project can be built by command: mvn clean package -Dmaven.test.skip=true. Write the Dockerfile to run your SpringBoot jar file. Please be noted you cannot read the ARG directly, but you can pass it to an env variable and read the variable instead.

FROM openjdk:8-jre
ARG PROFILE
ENV PROFILE_VAR=$PROFILE
VOLUME /tmp
## Add the built jar for docker image building
ADD target/hello-world-docker-action.jar hello-world-docker-action.jar
ENTRYPOINT ["/bin/bash", "-c", "java","-Dspring.profiles.active=$PROFILE_VAR","-jar","/hello-world-docker-action.jar"]
## DO NOT USE(The variable would not be substituted): ENTRYPOINT ["java","-Dspring.profiles.active=$PROFILE_VAR","-jar","/hello-world-docker-action.jar"]
## CAN ALSO USE: ENTRYPOINT java -Dspring.profiles.active=$PROFILE_VAR -jar /hello-world-docker-action.jar
EXPOSE 80

Unlike the shell form, the exec form does not invoke a command shell. This means that normal shell processing does not happen. For example, ENTRYPOINT [ “echo”, “$HOME” ] will not do variable substitution on $HOME. If you want shell processing then either use the shell form or execute a shell directly, for example: ENTRYPOINT [ “sh”, “-c”, “echo $HOME” ]. When using the exec form and executing a shell directly, as in the case for the shell form, it is the shell that is doing the environment variable expansion, not docker.

Another way to pass variables

There is another way to pass variables if the above way doesn’t work. You can put the command into a script file and add the shell as entrypoint.

FROM openjdk:8-jre
ARG PROFILE
ENV PROFILE_VAR=$PROFILE
VOLUME /tmp
## Add the built jar for docker image building
ADD target/hello-world-docker-action.jar hello-world-docker-action.jar

## Build a shell script because the ENTRYPOINT command doesn't like using ENV
RUN echo "#!/bin/bash \n java -Dspring.profiles.active=${PROFILE_VAR} -jar /hello-world-docker-action.jar" > ./entrypoint.sh
RUN chmod +x ./entrypoint.sh

## Run the generated shell script.
ENTRYPOINT ["./entrypoint.sh"]
EXPOSE 80

Write workflow to build jar

Add a step to run the maven building command in order to get the above jar file.

on:
  push:
    branches:
      - dev

jobs:
  hello_world_job:
    runs-on: ubuntu-latest
    name: A job to build and push docker
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8

      - name: Build with Maven
        run: mvn clean package -Dmaven.test.skip=true

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Login to DockerHub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKER_HUB_USER }}
          password: ${{ secrets.DOCKER_HUB_PASS }}

      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          file: ./Dockerfile
          pull: true
          push: true
          cache-from: type=registry,ref=hustakin/hello-world-docker-action:latest
          cache-to: type=inline
          tags: hustakin/hello-world-docker-action:latest
          build-args: PROFILE=nectar,ARG2=test

#github #docker #devops

What is GEEK

Buddha Community

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
• Basic Concepts of GitHub Actions
• Demo on Using GitHub Actions
• Creating a workflow file
• Configuring the workflow file
• Running the workflow file
• Conclusion

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

A Simple Guide to Github Page Deployment

Long story short: Jekyll is a template engine changing

markdowndocuments on staticHTMLwebpages, that you can then host anywyere, because you don’t need databases or server that has PHP or Python.

Usual Process

Normally the process of adding new post looks like this:

• I write markdown document with setting parameters like title, date and tags
• when I’m happy with what I wrote (never), I commit changes and push it to repository on GitHub. Repository name comes from my nick and is also address for blog asvid.github.io
• Github after pushing to branch master builds website from sources using Jekyll - probably something like running jekyll build
• result of Jekyll build is not present in a repository, but you see it right now after visiting bloga page

#github-pages #github-page-with-jekyll #jekyll #github-actions #github #deployment #continuous-deployment #web-development

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

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

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