With this complete GitHub Actions Tutorial 🎬 you'll get a good overview of:
- what GitHub Actions actually is,
- understand specific developer workflow use cases that you can automate with GitHub Actions
- how GitHub Actions works - basic concepts including GitHub Events, Actions and workflow
- the most common workflow, which is CI/CD pipeline
- understand why it's not just another ci/cd tool or what are the benefits of GitHub Actions CI CD pipeline
- hands-on demo, where I explain the syntax of github actions workflow file and then I show you a complete ci pipeline setup with my example Java Gradle project, which we will build into a Docker Image 🐳 and push to a private Docker repository on DockerHub.
GitHub Actions is a platform to automate developer workflows.
Many tutorials seem to convey that GitHub Actions is a ci/cd tool, but CI/CD is just one of many workflows.
What is CI/CD?
Continuous Integration: integrate developer's code into a shared repository. Each check-in is then verified by an automated build.
Continuous Delivery picks up where continuous integration ends and automates the delivery of applications to infrastructure environments.
So, what are those developer workflows? 👀
All these tasks are workflow examples of what you have to do as a maintainer of a GitHub repository.
The bigger the project gets and the more contributers you get and the more features, issues and pull requests are created, the more organizational effort you have 😦 .
And of course, as a developer you'd rather code and instead automate as much as possible of those management tasks!
For that purpose GitHub Actions was created 💡.
Obviously not everybody has an open source project on GitHub, so for your private project the most common workflow will be a CI/CD pipeline.
Every time when something happens IN or TO your repository (Events) you can configure automatic actions to be executed in response (Actions).
GitHub Actions are individual tasks, combined they result in a custom workflow 🔁.
So, how does this translates to the actual config file.
Your config file is a "workflow" of triggers ("on" - the events) and steps. You can have as many steps as you want.
These steps can be a combination of:
- shell commands - "run" (like npm run build, ./gradlew build, ...)
- external actions - "uses"
An external action is just a repo with actions.yml file published by the community, which is reusable for you.
So, it's a reusable flow which you can use like a library. You can find actions available in the Actions "marketplace".
The job is the "what" actually executes. You can name the job anything, but you only need one job in most cases.
The syntax of the workflow config file is YAML. Full YAML Tutorial here
Tip 💡: GitHub has a big list of workflow templates, so you don't have to write your workflow file from scratch. Use one of the templates that matches the technology your project uses.
These are just the key parts, you can watch the full tutorial for more detailed explanations.
Now let's look at a specific workflow example.
A simple CI/CD pipeline could look like this: You commit your code, the build starts, you test your code, you build your code into an artifact, push the artifact in some storage and then deploy the app to a deployment server.
Why is it a big deal to have just another CI/CD tool? Because
there are already well established ones like Jenkins.
- 👍 It's integrated in your code repository. If you're already hosting your code on GitHub, now you can use the same tool instead of setup integration with another third-party CI/CD tool
- 👍 The setup of the pipeline is easy
- 👍 It's a tool meant for developers
So, why is the setup easier? 🧐
To understand that you must know, that one of the most important things when setting up a CI/CD pipeline is its integration with different tools and technologies.
You don't want to configure each and every integration with those tools, like installing Java, Maven and Docker, integrations with Nexus, AWS, installing plugins and so on.
Instead you want a simpler way of saying:
"I want an environment with Node and Docker already available, with a version I want." And in the same way the deployment part should be easy by simply connecting to the target environment and deploying the application there.
That's exactly the advantage when using GitHub Actions! 🤩
In the below video in the demo part I show and explain how it works step by step.
Using an example Java Gradle project, which we will build into a Docker Image (because we live in a world of containerization 🐳) and push to a private Docker repository (DockerHub).
Watch the full video here 🤓
► Get 30% off - with this code: UDEMY_NANA_NOV2020: Udemy course here
► Kubernetes 101: Compact and easy-to-read ebook bundle 🚀
It's a handy way to quickly look something up or refresh your knowledge at work and use it as your cheatsheet 😎
Like, share and follow me 😍 for more content: