Transcripted Summary
Welcome to Chapter 2. In the last chapter, you learned a lot about GitHub Actions and also what it looks like.
Now, we are doing a deep dive into the components of GitHub Actions.
# GitHub Component: Event
The first one we want to focus on are GitHub Events.
GitHub Events
Events trigger the action. They represent an activity in the repository that will trigger a workflow run.
There are a lot of different events available on GitHub, and they are getting more and more. Meanwhile, there are more than 35 different events defined, which just shows us the potential of GitHub Actions.
Events you define in the workflow by using the keyword on as you can see also on the screen.
In this course, we will focus on and tackle some of these events like:
workflow_dispatch— to trigger a workflow manually; you already used that one in Chapter 1;scheduled— for example, if you want to trigger a nightly build;pull_request— when you want to run static tests, someone creates apull-request;repository_dispatch— this is for REST-API calls if you want to integrate GitHub actions with other systems; andissues— used to trigger a workflow after an issue gets created. Here is a very prominent term,issue-ops, so that something a process is triggered after someone creates an issue with a certain content.
The syntax, as an example, you can see here on the screen either like that's this one
on:
repository_dispatch:
types: [test-results]
Or that one:
on:
schedule:
# * us a special character in YAML, so you have to quote this string
- cron: "30 5,17 * * *"
You can see here repository_dispatch or schedule, but what's this blue thing?
What's these types?
The blue box was an event or GitHub event type, but what is this?
Each event can have several types kind of like a status of an event.
Let me explain it by example with the pull_request event.
After a pull_request gets created or reopened, you want to run static testing.
If you don't define anything, it will run based on the D4 configuration, which is most probably not what you want because it will be triggered for too many of these types.
So, we need to work with these event types.
You can see, for example, below how it will look if we use the pull-request event with the two types opened and reopened.
on:
pull_request:
types: [opened, reopened]
If you use more events or more event types, then you need to separate them with a comma.
There are really a lot of different event types for each event.
Just check out the issues event, which you can see on the right side of the image above. I mean, I don't want to count them, but I guess you already got the picture.
We have a lot of them and it's important here because you can really specifically react on your needs.
And if you use event, check all the types before.
Yeah, so maybe you can use some of them, which you're not aware of, you can check out the GitHub documentation. This one is very well maintained and up to date.
One more thing about events; you can also set branches on events.
What does this mean?
I'm sure you want to do different things, and if you're going to merge it into the main branch or you're going to merge into the release branch, these are different things.
Therefore, you can specify it with the keyword branch.
And to provide here some examples, you can react, for example, on features.
So, if there's a prefix feature or hotfix, release, or directly on the name of the branch, for example, main.
Now you know a lot about events, so we are ready to go to the next components, the jobs.
# GitHub Component: Job
GitHub Jobs
Jobs are a set of steps that run in sequence to accomplish a task. Each job runs on its own runner.
Jobs get configured in the workflow below the keyword jobs, and you can name your job the way you want.
This is kind of a free text. Each job is defined by a unique ID, which is basically the name of the job.
In our example, the ID of the jobs are “job1” and “job2”. I underlined them with a blue line.
Jobs always run in parallel.
Each job runs specifically on a runner, which is set with the keyword runs-on. You can see this one here on the line in green. You can see we use here “ubuntu-latest” as a runner.
Each job consists of multiple steps. What a step is, we will come to in a second.
Let me first explain this nice keyword, which I have underlined with red, which is the keyword needs.
I mentioned before that jobs always run in parallel.
Yes, that's true, except if you use the powerful keyword needs because this makes jobs dependent on each other.
In the example you see here 3 jobs — a setup job, a build job, and a shutdown job — and all these 3 are dependent.
The shutdown depends on the build. And the build depends on or needs the setup. I guess you got the point.
This feature we will use very often; it’s one of the core features because jobs are dependent on each other.
They have some relations. Cool.
And now we come to steps, as I already announced.
# GitHub Component: Step
GitHub Steps
Steps are either a shell script, or an action that will be run on the runner.
What are the capabilities of steps?
Steps are executed in order.
Steps are dependent on each other.
Each step is executed on the same runner.
Remember where the runner is defined? Yes, correct on the job level, and you can share data from one step to another.
In this example, we run 2 steps.
In this job we have defined steps, and we run 2 steps.
First, it's a GitHub Action, so it's the actions/checkout@v1, which is going to check out our source code.
And the next step, we run here a multi-line shell script.
For the multi-line shell script, we need to operate a pipe, so we need to start with the pipe symbol (|), and then we can write our shell code.
So, this is quite a simple one. We just run a build.sh script, and afterward, we run a test.sh script. That's it.
Simple and powerful.
# GitHub Component: Action
But what is this action? Let me elaborate on it a little bit.
GitHub Actions
Actions are individual tasks that you can combine to empower the jobs.
You remember we used an Action before to check out our code to the runner.
Actions are the building blocks that empower your workflow.
Actions are available from the community, so from the GitHub marketplace,
We also use that in Chapter 1, and you got already a small impression of it. There are more than 10,000 actions available, so it's really a huge marketplace.
And there, you can choose from GitHub or GitHub Actions, which are provided from GitHub have this prefix actions/.
And, of course, your own act Actions, which either you develop, or your team develops, or your company develops.
But you will learn more about that in Chapter 5.
Below you can see an Action from GitHub marketplace.
You remember it from Chapter 1. This one is approved by GitHub. So, it has this check sign.
I highly recommend using Actions that have this sign. It's kind of a quality mark from GitHub.
Let me explain how a step or an action is structured.
You can see here a step which causes an action, and the action has a prefix.
In this example, the prefix is actions/.
So, the first part is before the slash, this is the author of the action. In this case, GitHub.
After the slash, here comes then the action name. In this example, it's just javacript-action@v1.0.1.
Here is the action name, and then we have the at sign (@), and after the at sign, it follows the version number.
This could also be main, then it would always take the latest one.
It could also be a commit hash or, what is very often used, is the version number, which I also recommend.
So, this is it about actions.
# GitHub Component: Runner
And last but not least, let's put runners into the frontline.
GitHub Runners
A runner is a virtual machine (or any computer with a supported operating system) that runs the steps in a job.
Runners are quite simple.
At the end of the day, they are machines where the workflow is getting executed.
They get provided by GitHub, which is really cool, especially for the public and the communities.
And GitHub provides Ubuntu, Windows, and MacOS environments.
They get managed by GitHub, and they get thrown away after execution. So, this is really cool. You always get a clean instance as you have no interferences here.
And you can also use self-hosted runners.
It is very well documented how to set them up. It just takes you a few minutes, seriously. This is really great because you can use it with your own infrastructure. For example, to comply with certain standards and regulatory rules, security rules, especially if you are an enterprise company.
And here, it's not mandatory to clean the instance after each execution. It's recommended, yeah, but you need to consider if you have any interferences between the runs.
Now, you really know a lot about all these components.
Of course, it was a lot of theory. And in the next chapter, we will use our knowledge.
We will deep dive into the workflows and some specific events, and we will create our first workflows.
So, I will be happy to see you in Chapter 3.
Resources
- GitHub Documentation: Events
- GitHub Documentation: Understanding GitHub Actions
- GitHub Documentation: Event Types
- GitHub Marketplace: Actions
- Git Repo Course Code: Work with GitHub Actions
