Complete GitHub Actions Course - From BEGINNER to PRO

0:00Hey team, Sid here with DevOps Directive

0:02and welcome to this complete GitHub

0:04actions course. I spent the past few

0:05months building out what I believe to be

0:07the best resource for learning to use

0:09GitHub actions effectively and I'm

0:10excited to release it to the world. This

0:12course is for software engineers and

0:14DevOps practitioners who want to level

0:15up their ability to leverage GitHub

0:17actions within their teams and

0:18organizations. Over the next three and a

0:20half hours, I'm going to cover

0:21everything you need to know about GitHub

0:23actions. Starting with a solid

0:24foundation of platform capabilities,

0:26establishing the skills required to

0:28author automation workflows to meet the

0:30needs of your teams, and wrapping up by

0:31utilizing all of the skills and

0:33knowledge from the course to build a

0:34robust DevOps system based on GitHub

0:36actions containing workflows for

0:38building, testing, and deploying

0:40applications. While you're probably

0:41watching this video on YouTube, the

0:43video is just one component of the

0:44course. There's also a companion GitHub

0:46repo containing all of the code and

0:48workflows so you can follow along. Each

0:50lesson has a written module that you can

0:52see over at courses.devopsdirective.com

0:54and there's a Discord community where

0:56you can join to interact with other

0:57community members if anything isn't

0:59clear or you get stuck along the way.

1:00Thanks to my sponsor namespace, I'm able

1:03to provide this content to you free of

1:04charge. That being said, if you end up

1:06getting value from the course, you can

1:07help show your support by liking the

1:09video and sharing it on Twitter,

1:11LinkedIn, or within your company.

1:13Throughout the course, I'll go back and

1:14forth between theory sections where I'm

1:16covering all the different features that

1:17you need to know about and explaining

1:19how to use them and then practice where

1:20we'll jump into the code editor, view,

1:22author, and edit workflows and actions

1:24and run them both locally and remotely

1:26on GitHub to solidify your understanding

1:28of the various concepts. As I mentioned,

1:30this course is for any software engineer

1:31or DevOps practitioner who wants to

1:33level up their ability to use GitHub

1:35actions. This could be because your

1:36current CI pipelines are taking too long

1:38and you want to understand how to

1:39effectively use caching, parallelism, or

1:41higher performance runners to speed that

1:43up. It might mean you're starting some

1:44new projects and want to do so in the

1:46right way with automated workflows built

1:47in from the start. Or you may have

1:49inherited a mess of YAML from a previous

1:51engineer and you want to learn how to

1:52understand and refactor it into a

1:54modular maintainable system. Throughout

1:56the course, we'll learn the skills to do

1:57any of these things and how to use

1:59GitHub actions most effectively

2:00throughout your organization. There are

2:02some prerequisites for this course.

2:03First, I'm expecting you to at least

2:04have a base level understanding of Git

2:06and GitHub. Things like how to clone a

2:08repo, how to create branches, commit

2:10those, create PRs from those branches.

2:11I'm also assuming that you have a

2:13general idea of how to interact with a

2:14Linux shell or terminal, as well as

2:16writing and editing YAML files, which is

2:18the format that GitHub actions workflows

2:19are authored in. I'm expecting you to

2:21have at least some coding ability in one

2:23or more languages. This could be

2:24JavaScript, TypeScript, Go, Python, but

2:26the ability to read and write code is

2:28somewhat necessary. And then finally, an

2:30optional prerequisite around Docker and

2:32containers. there is the ability to

2:34create containerized actions and so for

2:36that having an understanding of how

2:37Docker works will be helpful. I also

2:39have a comprehensive course on Docker

2:40and containers that you could check out

2:41if you wanted to brush up on those

2:42skills. Before we dive into the course

2:44content, I do want to pause for a minute

2:46and thank the sponsor of this course,

2:47Namespace. It's only through their

2:49generous support that I'm able to

2:50provide this course to you completely

2:52free of charge. I'm excited about them

2:53as a sponsor because I want everyone

2:55using GitHub actions to know about them.

2:57Their products enhance the GitHub

2:58actions user experience and enable teams

3:00to build, test, and ship software

3:01faster. modifying just a single line in

3:03your configuration files, enables you to

3:05use namespace hosted runners, which can

3:07speed up your workflows while reducing

3:09costs significantly. But that's just the

3:10start. They also offer blazingly fast

3:12caching, remote Docker builders for

3:14speed ups when building container

3:15images, and best-in-class observability

3:17with access to things like job timing

3:19and resource utilization not available

3:21in GitHub directly. While using

3:22Namespace is not required to get the

3:24most out of the course, I will be

3:25showcasing where and how to use

3:27namespace tools to improve your

3:28experience when working with GitHub

3:30actions. If you want to get started with

3:32Namespace, there's a link in the

3:33description that you can follow. Full

3:34disclosure, this link is an affiliate

3:36link, so I will get some payment if you

3:37end up using Namespace. Because of this,

3:39if you do use them, I would appreciate

3:41if you use the link, and let them know

3:42that you learned about them from me. So,

3:44what are we going to cover in the

3:45course? We'll start by providing some

3:47context in terms of what GitHub actions

3:49is, where it falls within the landscape

3:51of continuous integration tools before

3:53covering all of the platform features

3:55that you're going to know about from the

3:56basic core features to the more advanced

3:58features as well as how to utilize the

4:01third party public marketplace action

4:02which is one of the big selling features

4:04of GitHub actions before authoring some

4:06actions of our own to use within our

4:07workflows. We'll then move on to how to

4:09engineer workflows that are going to

4:10meet the needs of your organization by

4:12examining some of the common workflow

4:13types, how to improve the developer

4:15experience when working with GitHub

4:16actions, as well as best practices that

4:18you can apply to your teams and

4:20organizations to make your experience as

4:21good as possible. Finally, we're going

4:23to tie all of this together in an

4:25end-to-end capstone project where we'll

4:27implement six different workflows that

4:28include testing, building, deploying a

4:31microserbased application, all using

4:33GitHub actions. And now with those

4:35logistics out of the way, we can go

4:37ahead and dive right into the course. In

4:38order to provide historical context on

4:40why a tool like GitHub action exists in

4:43the first place, it's useful to take a

4:44look back through the history of

4:46software development and understand why

4:48continuous integration is a thing and

4:50where GitHub actions fits within the

4:51landscape. At the very early days of

4:53computing, things were done via physical

4:56punch cards. You would encode your

4:57program into a piece of paper with holes

5:00punched in it and then those would be

5:01fed into a machine that would perform

5:03the desired calculations and output some

5:05result. This process took quite a long

5:07time and generally the people writing

5:09and producing the software were the same

5:10ones consuming it. These were executed

5:12on big mainframe systems. There was no

5:14notion of personal computing. So you

5:15weren't really delivering software out

5:17to an end user. Uh you were writing the

5:19software for your own needs, executing

5:20it. And because of the amount of effort

5:22to to author and generate these punch

5:24cards, the time between updates was

5:26generally very very slow. The delivery

5:27mechanism moved from these physical

5:29punch cards onto things like floppy

5:31discs or compact discs or eventually

5:33DVDs. These devices could be written to

5:35digitally and then you could ship

5:36usually via snail mail this device to an

5:39end user who would install it in their

5:41machine. Because this required shipping

5:43a physical device via snail mail, the

5:46time between updates was still quite

5:47slow on the order of months probably.

5:49and the cost to ship an update was quite

5:51high. Continuing forward in time to the

5:542000s and the dotcom boom, uh we started

5:56to see websites and the internet take

5:59hold and software be delivered via the

6:02internet. So rather than needing to

6:04physically ship something to an end

6:06user, you could deliver a website or web

6:08app to the end user immediately over the

6:11internet. And this enabled a much

6:13quicker turnaround for shipping software

6:15updates. Now, in conjunction with this,

6:17because we're now able to ship updates

6:18much more quickly, the importance of the

6:20ability to automatically test updates

6:22before they ship became higher and

6:24higher. Now, we move into the 2010s and

6:27into the 2020s where we are today. And

6:29the highest performing software team are

6:30shipping updates multiple times per day.

6:32Because of this, the tooling for

6:34building out and automating tests has

6:37continued to evolve. And that's where

6:39continuous integration tools like GitHub

6:41actions really start to shine and become

6:43critical for these teams to ship quickly

6:45and safely. For those who are writing

6:47software today, the idea of continuous

6:49integration and automated testing may

6:51seem like table stakes, but before the

6:53year 2000, this was a totally novel

6:55idea. Companies were obviously building

6:58and testing their software, but this was

7:00often performed in a manual fashion on

7:02enduser machines rather than testing

7:05every single change automatically as it

7:06makes its way into version control.

7:08Looking way back to 1997, uh, one of the

7:12first uh, examples of continuous

7:13integration tooling came into play out

7:16of Netscape, eventually into Mosilla,

7:18and that was Tinderbox. Uh and so this

7:20was a tool which would automatically

7:22look at their version control and for

7:24each new commit it would attempt to

7:25build the software for all the different

7:27platforms that they were going to deploy

7:28to and then it would report the status

7:30of those builds back via this web

7:32interface. And this was a pretty

7:33revolutionary idea and it enabled those

7:35teams to see if there was a regression

7:37introduced and one of the builds failed

7:38to identify the bug and then fix that

7:40much more quickly. A few years later in

7:422001, uh, cruise control came onto the

7:45scene that was written in and primarily

7:47used by teams building software using

7:49Java. Similar idea, the ability to build

7:51your software and execute your test

7:53suites against them. Came out of a

7:54company called Thought Works a handful

7:56of years later in 2005. Uh, Hudson was

8:00introduced. Hudson came out of Sun

8:01Microsystems, eventually acquired by

8:03Oracle. uh and it provided kind of a

8:05more user-friendly user interface and a

8:08very large plug-in ecosystem that

8:10enabled you to handle a variety of use

8:12cases via those plugins. Eventually, it

8:14was forked and kind of lived on in the

8:17form of Jenkins uh due to some copyright

8:19issues with Oracle and the community

8:21wanting a more open version of the

8:23software. Some other key players in the

8:25space like Atlassian and Jet Brains

8:27introduced their own continuous

8:28integration tools around 2006 2007. And

8:31the interesting thing about these is

8:33that they had strong integrations with

8:34their existing product suites. So

8:36Atlassian was able to build bamboo and

8:38have tight integrations with their with

8:40their tools like Jira and Bitbucket.

8:42Whereas Team City was able to provide

8:44integration with their suite of idees or

8:46integrated development environments that

8:47they specialize in. If we move forward

8:49to 2010, we start to see some more

8:51familiar names come onto the scene like

8:53TravisCI and CircleCI. Now, with these

8:55new entrance to the market, these were

8:57some of the first software as a service

8:59model continuous integration providers

9:01where the company is generally hosting

9:02your runners and executing those builds

9:04as part of a cloud SAS. And these really

9:06push forward the developer experience

9:08and the user experience of uh making it

9:11easy to integrate a CI tool with your

9:15version control uh and set up automated

9:17builds. Now on the top there, we start

9:19to see entrance from the major version

9:21control platforms come into play. First,

9:24GitLab with their CI/CD product and then

9:26eventually in 2018 with GitHub actions.

9:29I'll talk about some of the reasons you

9:31might choose these different tools

9:33relative to each other. But when a

9:35version control platform uh releases a

9:37tool like this, they're able to have

9:38deep integration hooks with the rest of

9:40their platform, which can make it quite

9:42nice if your code is already hosted

9:43there. 2016 with AWS code build that was

9:46the first sort of entrance from a

9:47hyperscaler cloud. Uh GCP and Azure have

9:50their own CI tooling that was introduced

9:53not long thereafter. It can be useful if

9:55you're building and deploying your

9:57software all within one of those

9:59hyperscalers and you want to keep your

10:00builds and test infrastructure there as

10:03well. This just provides a timeline some

10:05of the key entrance in the history of

10:07continuous integration. As you can see

10:09GitHub actions was kind of a late

10:10entrance. Uh however, because it is tied

10:13to GitHub and that is the de facto

10:15standard where most teams are hosting

10:17their version control, it has a super

10:19low barrier to entry to getting started

10:21with. There's even an allocation of free

10:23build minutes that are provided for open

10:25source repos. So because it is so easy

10:27to get started, they've really ramped up

10:29quickly and become one of the more

10:30dominant players in the space. And now

10:32let's think a little bit about the types

10:33of workflows that people are running

10:36within these continuous integration

10:37tools. There's four main categories that

10:39I think of. Uh the first is sort of

10:41validating things about your code and

10:44the changes to your code. So this is

10:45things like linting to make sure that

10:47your code is all formatted correctly and

10:48there's no type errors etc. This is

10:50things like testing whether it's unit

10:52testing or integration testing or

10:54endto-end testing. Things like static

10:56analysis of which linting is a specific

10:58type but looking at security issues with

11:00your code either in dependencies or in

11:01how it's written or code quality

11:03metrics. So these type of validation

11:05checks are very common. The second

11:07category would be uh building your

11:09software. So for a compiled language

11:11this would be building the executable

11:13itself. Uh for other languages this

11:15might be taking your software

11:18downloading all the dependencies and

11:20bundling those into some deployable

11:22artifact like a container image. The

11:23third category then would be to take

11:25those deployable artifacts either the

11:27binary or the container or some virtual

11:29machine image and deploying those into a

11:32server somewhere that could be in the

11:34cloud that could be on premises. There's

11:35two main categories of deployment

11:37workflows. I would say the first is

11:38pushbased. So from within a workflow

11:40authenticating to that server or that

11:42Kubernetes cluster or whatever the

11:44deployment target is and issuing a

11:46command to to push that deploy from the

11:49workflow. The other one uh that has

11:50become more common recently is a GitOps

11:53model where you have some agent running

11:54inside of your deployment target that is

11:56looking back at the version control and

11:58pulling in updates automatically. I'll

12:00talk more about how these work later on

12:02in the course. And then the fourth is

12:03sort of a broad category of repo

12:05automation. So because GitHub actions

12:08has the ability to respond to lots of

12:10different types of events in GitHub, you

12:11can have things that are outside of

12:14traditional continuous integration to

12:16automate facets of your repositories.

12:19Things like uh automating the release

12:21process based on commit messages. Uh

12:23checking for issues or pull requests

12:25that are stale and closing those

12:27automatically or things like finding

12:29potential dependency updates uh and

12:31executing those or creating PRs for

12:33those. all sorts of different

12:34automations that you can apply to your

12:36repositories. Now that we understand the

12:38context of GitHub actions and the

12:40history of continuous integration

12:41systems, let's talk a little bit about

12:43why you might choose GitHub actions over

12:45some of the alternatives. I found two

12:46industry surveys that ask many different

12:48developers which type of CI/CD pipeline

12:51tooling they are using. Uh one was from

12:53the CNCF, the CloudNative Compute

12:56Foundation, their annual survey, and one

12:58from Jet Brains, so the IDE development

13:01company. And both of these asks a very

13:03similar question. What type of CI

13:05tooling or pipeline are you currently

13:07using? As we can see from the CNCF

13:10survey, GitHub actions is the most

13:12popular option. We also see some tooling

13:14like Argo and Flux there that are really

13:16focused on only the GitOps or CD

13:19portion. So we kind of eliminate those.

13:21And so we look at the top few. It's

13:22GitHub actions, Jenkins, GitLab, and

13:25then Azure Pipelines, which is quite

13:26similar to GitHub actions. In fact, the

13:28GitHub actions runner codebase is a fork

13:30of the Azure pipelines runner uh back

13:32when they initially launched. Over on

13:33the JetBrain survey side, we can see

13:35Jenkins is in that top spot followed by

13:37GitHub actions and then GitLab. If we

13:39think about why Jenkins might be in the

13:41top spot there versus in the CNCF one,

13:43CNCF is going to be almost entirely

13:46companies and developers who have

13:47adopted Kubernetes and therefore are

13:49likely to adopt more recent or modern

13:52tooling. And so that's why I think

13:52GitHub action shines there versus if you

13:54take the broader set of software

13:56developers many of them maybe at larger

13:58more enterprise companies with legacy

14:00installs of Jenkins which has been

14:01around for a lot longer is much more

14:03common in some of those large enterprise

14:05settings and is operating projects that

14:06have been around for quite some time

14:08perhaps even longer than GitHub actions

14:10itself. Here I've mapped out a table

14:12kind of comparing these top handful of

14:15tools. So GitHub actions, GitLab, CI/CD

14:17and Jenkins were the three that we saw

14:19at the top of those surveys. And then I

14:20also included CircleCI as a CI provider

14:23not linked to a particular version

14:25control platform but is able to link

14:27into many of those platforms and

14:29provides a bit of contrast to Jenkins

14:30which is usually self-hosted whereas

14:32CircleCI they're generally hosting the

14:34runners for you. As I mentioned earlier,

14:36one of the big reasons that people get

14:37started with GitHub actions is because

14:39their code is already on GitHub. There's

14:41minimal barrier to entry. You just add a

14:42YAML file to your repo and this low

14:44friction means people start there and

14:46often end up staying there. There's also

14:48an expansive public marketplace so

14:50people can publish their own uh actions

14:52which are steps within your your

14:54pipelines that you're going to execute

14:55for many different common continuous

14:57integration tasks. You can find a public

14:59action that performs what you need to do

15:01and avoid having to write and maintain

15:03that code yourself. And then another

15:04reason why people choose GitHub actions

15:06is because they are a market leader. It

15:08leads to improved tooling. There are

15:10many companies building on top of GitHub

15:12actions just like the sponsor of this

15:13course namespace to build faster

15:15runners, better user experiences. Uh,

15:17and so that improved tooling is kind of

15:19a positive feedback loop where it's a

15:21better experience which leads to more

15:22adoption and so on and so forth. Some

15:24reasons you might not choose GitHub

15:26actions is if your code is living

15:27elsewhere if it's in GitLab or Bitbucket

15:29or some other version control system.

15:31GitHub actions has less powerful

15:33expressiveness than some of these other

15:35systems. It's it's a simplistic syntax,

15:37but it does mean that in certain cases

15:39you end up copying and pasting rather

15:41than being able to compose pipelines in

15:43a reusable fashion. We'll look at how to

15:45write and debug actions, but out of the

15:48box, the debugging experience can be

15:50somewhat painful and also the default

15:52observability and analytics for GitHub

15:54actions is quite limited. There's tools

15:56to help improve this and using a

15:59provider like namespace will give you

16:00some better observability, but out of

16:03the box it can be quite limited. GitLab

16:05is an obvious contrast to GitHub

16:07actions. Similarly, it is tied to the

16:09version control platform and so if your

16:12code is on GitLab, you're likely going

16:13to choose GitLab CI. Again, if you are

16:16in that ecosystem, it's a minimal

16:17barrier to entry. Has deep integration

16:19with all the other GitLab features. And

16:21GitLab has an interesting approach of

16:22auto DevOps. Allows you to bootstrap an

16:24end-to-end CI system. If you're in a

16:27common language ecosystem that they have

16:29added this type of capability for

16:31negatives for GitLab is if you are not

16:32using GitLab, you cannot use GitLab

16:34CI/CD. And also their marketplace

16:37features. So their ability to to share

16:38and consume thirdparty capabilities is

16:40significantly smaller uh than GitHub

16:42actions. Whereas there's there's less

16:44than 500 total actions in that

16:46marketplace. Whereas GitHub actions has

16:48thousands and thousands. The quality of

16:50the actions in the GitHub action

16:51marketplace varies wildly. Uh but

16:54because there are so many more, the

16:55likelihood that you'll find a

16:57highquality action that does meet your

16:59need is much higher. for CircleCI. If

17:01your code is not in one of those two

17:02major providers, but you still want a

17:05sort of cloud hosted CI system, CircleCI

17:08might be a really nice option. There is

17:09a feature that they have built in uh

17:12called retry with SSH that when a step

17:14in your pipeline fails, you can actually

17:15retry that workload and get instant

17:17access to the environment where that

17:19pipeline is running, which allows you to

17:20poke around and debug. There are ways to

17:22achieve this on GitHub actions and other

17:24platforms, but having used CircleCI in

17:26the past, that feature is one that I

17:27miss uh when using some of these other

17:29platforms. It does require some

17:31additional initial setup. It's not tied

17:33directly into the version control

17:35platform like these first two. Uh and

17:37also like GitLab, its public marketplace

17:39for orbs is what they call kind of the

17:41reusable unit uh is larger than GitLab,

17:44but it's still significantly smaller

17:46than GitHub actions. Now, the fourth one

17:48here, Jenkins, as I mentioned in the

17:50history section, has been around for

17:52much, much longer than any of these

17:53other tools. There's kind of two

17:55positives for it. I would say the first

17:57reason I can think of that someone would

17:59use Jenkins is that it is already set up

18:01and running and they don't want to

18:02invest to switch off of it. Uh so there

18:05is some switching cost to rewriting

18:07pipelines and moving things elsewhere.

18:09And so often times if you have an

18:12existing setup and it works, uh if it

18:14works, there's no reason to break it.

18:15The plug-in ecosystem is quite vast. So

18:17there's a number of capabilities that

18:18you can achieve within Jenkins by using

18:21those thirdparty plugins. Kind of

18:22similar to the to the GitHub actions

18:24marketplace. There's a lot of

18:26capabilities that have been built up

18:27over the lifetime of that tool. Some

18:29negatives or or why might you not want

18:31to use Jenkins is that it is generally

18:33known for having quite a high

18:35maintenance overhead. Sort of keeping up

18:37with plugins as they are updated or have

18:39security issues can be a significant

18:42piece of work. uh and also the

18:44authorship of the pipelines writing them

18:46in is a language called Groovy which

18:48isn't really used much elsewhere outside

18:50of the Jenkins ecosystem uh and it can

18:52feel kind of quite outdated relative to

18:55the YAML structure that you may be

18:57familiar with if you're using these

18:58other tools. Now, before we start

19:00examining and authoring and running uh

19:02GitHub action workflows, I want to pause

19:04and make sure we set up your development

19:06environment appropriately so that you

19:07have all the tooling that you need to

19:09follow along with the steps that I'm

19:10performing and ideally minimize the

19:13number of snags that you hit along the

19:14way. Now, the first step that you're

19:15going to want to do is to fork the repo

19:17and then clone it to your local system,

19:19including the sub modules. Now, the

19:21reason that we fork it here is because

19:23that way you can be the owner of the

19:24repo on GitHub, which will enable you to

19:26execute the workflows as you look at

19:28them, modify them, and then you'll want

19:29to run them within your own forked copy

19:31of the repository. This is the repo for

19:34the course. It's at github.com/palace

19:36devopsdirective GitHub actions course.

19:38To do that, you'll navigate to the

19:39repository. You'll go over here to the

19:41fork button. And while you're here, you

19:42may as well give it a star, but you'll

19:44click the fork button. You'll give it a

19:46name, choose which account or

19:48organization you should make it a part

19:49of, and then you'll click create fork.

19:51Once you've done that, you can scroll

19:52down in the readme and find this get

19:54clone command and just modify this to

19:56reference your forked copy rather than

19:58the repo under my name. Because we've

20:00included recurs subm modules, we'll get

20:02the capstone repo as well. Eventually,

20:04when we start working on that, you may

20:05want to fork it as well, but for now,

20:07pulling in my copy should be just fine.

20:09Next, we'll install a tool called

20:10Devbox, which gives us a reproducible

20:13shell environment with all the tooling

20:15that I use throughout the course pinned

20:16to the exact version that I'm using. So,

20:18you shouldn't hit any version dependency

20:19issues. The best way to do this is to go

20:21to their documentation, choose the

20:23system that you are running on. So, in

20:25my case, I'm on Mac OS and I can run the

20:27script to install it. Hey, Sid from the

20:30future here. Uh, as I was editing this,

20:31I realized I didn't mention this, but if

20:33you are on Windows, you should be using

20:35WSL such that you're executing these

20:37from within Linux. Uh I haven't tested

20:39any of this on Windows directly. Uh and

20:42so you'll have a much better time if you

20:44work within a Linux environment under

20:45WSL. Mac OS is the system that I use to

20:48develop and test all this. And then

20:49because we're using Devox which

20:51leverages Nyx under the hood package

20:52manager, hopefully things will work

20:54seamlessly across Mac OS, WSL on Windows

20:56or Linux directly. All right, back to

20:58the video. Once it's installed, uh there

21:00is a devbox.json at the top level of the

21:03repo as well as a devbox.lock file. Uh

21:07these are what tells Devbox which tools

21:09to install. You can see all these tools

21:10that I'm using. I'm specifying latest

21:12here. That's I'm using latest at the

21:14time of recording. But by using this

21:16lock file, you will get the exact

21:17version that I have installed on your

21:20system. The nice thing about Devbox is

21:21it gives you this environment isolated

21:23from anything else on your laptop such

21:25that when you're working on the course,

21:27you can have these versions pinned to my

21:28exact versions. But if you're working on

21:30something else, it won't pollute those

21:31installs elsewhere. Once you have Devbox

21:34installed, you can just run Devbox shell

21:36and it will look at your current

21:37environment, download and install any

21:40tooling that is not there and start a

21:42shell session with all these tools

21:44installed and configured accordingly.

21:45Then we'll install Docker Desktop which

21:47is useful as we get into some of the

21:48containerized aspects uh of building

21:51containerbased actions andor using uh

21:54the tool ACT which allows us to run

21:56GitHub actions workflows locally within

21:58containers. So having docker installed

21:59is useful for that. for Docker Desktop.

22:01Follow the latest uh install

22:02instructions from their documentation.

22:04Choose the platform that you're on and

22:06follow the instructions there. And then

22:08finally, I'm going to be using VS Code

22:09throughout the course. You could use

22:10other editors, but these are two

22:13extensions within VS Code that I found

22:14helpful for working with GitHub actions

22:17specifically. The first one is YAML.

22:18This will give you YAML syntax

22:20highlighting as well as linting

22:21capabilities. And the second one is the

22:23GitHub actions uh VS Code extension. So

22:26if we go into VS code and you go under

22:28code settings extensions now you can

22:31search here for GitHub actions you can

22:34install that there. Uh this is the

22:36official one. There's this other one

22:37here as well. I'm using the official

22:39one. It does provide a few nice things

22:41around actually viewing the actions that

22:43have run in your repositories from

22:45within VS Code. I don't use them that

22:47much but it's it's nice to have

22:48installed. And then the second one is

22:50the YAML extension here from Red Hat. I

22:52go ahead and install that. One thing I

22:54did notice though uh when I set both of

22:56these up, the GitHub actions extension

22:59actually sort of takes ownership of any

23:01YAML file in those specific

23:03subdirectories such that the YAML

23:05extension was no longer recognizing them

23:07as the YAML type. And so I added this to

23:10my settings files.associations such that

23:13any any YAML file in

23:14that.github/workflows

23:16uh directory will be still associated

23:19with the YAML extension. And then

23:21similarly, uh, task files were not being

23:23recognized as YAML. And task is a tool

23:25we use throughout the course for storing

23:27and running specific little shell

23:29commands and and and scripts. And so by

23:32adding it to this settings.json, now the

23:36YAML linting and auto formatting worked.

23:38Again, you can set these from within the

23:40GUI if you don't want to use the

23:41settings.json file by going under code

23:44settings uh settings and then searching

23:48association.

23:50And you can see here uh for my user I

23:52have files matching those two patterns

23:55associated with the YAML file type such

23:57that the extension can do its job

23:58appropriately. Okay, the time has come

24:00for us to actually take a look at and

24:03write and run some GitHub action

24:05workflows. This next module is going to

24:07focus on some of the core features and

24:08then the following module we'll look at

24:09some of the more advanced features. This

24:11will get you up and running with the

24:13basics of what you'll need to run within

24:14GitHub actions. And then throughout the

24:16rest of the course, we'll start to learn

24:17how to use these tools more effectively

24:19and design workflows that are really

24:21going to help your team execute at a

24:22high velocity. Before we actually look

24:24at the YAML configurations though, let's

24:27talk about some of the terminology so

24:28that we're all on the same page in terms

24:30of the different concepts you need to

24:31know and how we refer to them. On the

24:33lefth hand side are GitHub events. So

24:35these are things like pushing to a

24:37branch in GitHub, creating a pull

24:39request. Any event that happens via the

24:41GitHub API or that you could have access

24:43via the GitHub API generally you can see

24:46and respond to from GitHub actions.

24:48These are going to trigger what is

24:50called a workflow. And so workflow a

24:52workflow is what they call pipelines in

24:54GitHub actions. So the thing that you

24:56are authoring your file represents a

24:58workflow. Within that workflow there

25:01will be one or more jobs. Each of those

25:03jobs can have one or more steps within

25:05them and they could be ordered in a

25:07specific manner as you can see here from

25:09this graph. And finally, the runner is

25:12the actual server environment that is

25:14going to execute those jobs. So between

25:17steps, you're in the same comput

25:18environment. Across jobs, you're in a

25:20different compute environment. So you

25:21need to think about that in terms of

25:22passing data or sharing environment

25:24variables or state between these

25:26different elements. Here's essentially

25:28the most simple workflow you can author.

25:30uh it's only 10 lines including a couple

25:32of blank lines. We can see those

25:34concepts from the previous slide mapped

25:36onto it. So in the on section there on

25:38line three, we've got a GitHub event. Uh

25:41in this case, we're using the workflow

25:42dispatch event. That just means it's a

25:44manual trigger. So we can go into the

25:45GitHub UI and click trigger. We'll talk

25:47more about how to use the different

25:49events. For example, we could have a

25:50push event for when it pushes to a

25:52specific branch or a pull request event

25:54for when we create a pull request. For

25:56now, we're just going to use that

25:57workflow dispatch in many cases so that

25:58we can manually trigger and see these

26:00things executing. Based on the outlined

26:02colors of those boxes, you can see the

26:04workflow is the entire thing. Jobs is a

26:06list within that workflow. And then

26:08steps is a list within that specific

26:10job. In this case, we have a single

26:12workflow containing one job and one

26:13step. And then there on line 8, the runs

26:16on key specifies what type of execution

26:19environment you want to have. U24.04

26:22is a runner type hosted by GitHub

26:24itself. If you wanted to run on Mac OS

26:26or Windows, you would specify that here.

26:28Or if you wanted to run on a thirdparty

26:30service like namespace, you would

26:32specify one of their runner types in

26:33this field. We'll go more into that

26:35later in the advanced section, but it's

26:36necessary to understand specifying

26:38Ubuntu 24.04. There means that we're

26:40going to get a runner hosted by GitHub

26:42running Ubuntu on that version. Let's

26:45jump over to GitHub in the browser and

26:48see this workflow in action. So if you

26:50go to the repo under the actions tab,

26:52you'll see all the different workflows

26:53that you have within your repo here. If

26:55I go to the hello world workflow, I can

26:57then click run workflow. And this button

26:59is only available because I have that

27:01workflow dispatch trigger in my

27:02workflow. I can run it from a particular

27:04branch. In this case, I'll run it from

27:05main. I'll click run workflow. Now if I

27:09refresh the page, we can see a run of

27:11that workflow has shown up. It's in a

27:13cued state. So it's waiting for a GitHub

27:15action runner. If I click into it, we

27:18can see it has now executed and it has

27:20run the command that I had in my step.

27:23Hello from an inline bash script in a

27:24GitHub action workflow. So that's the

27:26most simple workflow you can have. Now

27:28what are the different types of steps

27:30you can specify in a different workflow.

27:32Let's expand our hello world workflow to

27:34have three jobs each containing one step

27:36and this will highlight the different

27:38types of steps that you can have. And so

27:40what have we actually changed here in

27:41this uh in this update? You can see in

27:45the first step, it's almost identical to

27:47before. We're executing an inline bash

27:49script. That's the default shell on the

27:51runner. In the second job, we've

27:53actually modified that to use the Python

27:55shell. So now instead of writing bash,

27:57we can write Python. And then in the

27:59third one, we're using a third party

28:01open source action. This is the hello

28:03world JavaScript action. Uh and I've

28:05shown a screenshot here of that repo.

28:07And so we're able to leverage this

28:10external action to execute as a step

28:13within our job. And now let's jump over

28:15to our code editor and look at this

28:16workflow there. So as you can see, I

28:19made a few tweaks. I made this a little

28:21bit more verbose. So we know this is

28:22running from the bash script. This is

28:24running from the inline Python script.

28:25Uh and here we're specifying that third

28:27party action still, but rather than

28:29specify a version, we're actually going

28:31to tag the specific commit hash of the

28:33version we want to run. We're going to

28:34talk more about why that is from a

28:36security perspective and a stability

28:37perspective. Uh, but just know for now,

28:39you can specify either as a specific git

28:42tag or as a commit hash, but the commit

28:44hash is better practice. These longer

28:47strings didn't fit on the slide, that's

28:48why I didn't include them. Now, we can

28:50jump into the GitHub user interface and

28:52run a copy of this. So, I called this

28:54workflow step types. So, we can navigate

28:56to it here. Run it via the workflow

28:58dispatch.

29:00see that it's executing.

29:03Each of those three jobs is running in

29:04parallel.

29:07We can see they all succeeded and

29:09executed the commands that we expected.

29:12The Python executed accordingly

29:18and that third party action

29:22printed the output we would expect.

29:25Those are the three primary types of

29:26steps that you can run within your

29:27GitHub action workflow. either bash,

29:29Python, or a GitHub action as a step.

29:33However, there's one thing we haven't

29:35touched on here. You saw those three

29:36jobs ran in parallel. We can also tell

29:39GitHub actions to structure these jobs

29:41in a specific order by adding

29:44dependencies in the form of needs within

29:46the job specification. So, workflows

29:49form what's called a directed as graph

29:51or a DAG. And we can use that needs key

29:53to say which jobs depend on which other

29:55jobs. This will produce a structure like

29:58shown in that screenshot and allow us to

30:00take outputs from one job and pass them

30:02to another. So here I'm showing in the

30:04first job we can run a sequence of

30:06steps. The second job we can run an

30:08independent step which is not connected

30:10to job one in any way. But then by using

30:12needs jobs one and two for job three and

30:15needs jobs two and three for job four.

30:17We're going to ensure that jobs one and

30:19two execute first in parallel then job

30:21three and then job four. Let's jump over

30:23to the browser and run a copy of this.

30:27I called this workflow jobs and steps.

30:30We can run workflow run.

30:34Clicking into it, we see that structure

30:36as specified within our YAML. Jobs one

30:38and two have completed allowing job

30:40three to be picked up. And only after

30:43job three completes will we see job 4

30:46execute.

30:48It is an asyclic graph. So you cannot

30:50have a loop. You need to have a flow in

30:52one direction. That's how you specify

30:54the structure of your jobs within a

30:55workflow.

30:57So far, we've been using the workflow

30:59dispatch as a manual trigger that we can

31:01utilize from within the GitHub

31:03interface. That one's actually less

31:05common, but it's useful for an

31:06educational setting like this. The types

31:08of events that I see used more

31:10frequently are highlighted here within

31:12this list of all the events. Uh the

31:14first one we've been seeing that trigger

31:16manually with the workflow dispatch. The

31:17second one pushed to a branch. So you if

31:20you you can set it to trigger a workflow

31:22on a push to any branch or you can

31:25filter to specific branches. For

31:26example, you might want to filter to

31:28your default or main branch. Uh you can

31:30also as I mentioned trigger workflows

31:33based on a pull request event. So that

31:35could be the creation or update of a

31:37pull request. You could filter that so

31:39it only issues on pull request against a

31:41certain branch. There's lots of control

31:43here within how you structure these. And

31:45then the final one that I see most

31:47frequently is running on some timed cron

31:50schedule. Maybe you have something that

31:51runs nightly or weekly and you're able

31:54to use this schedule type of a

31:56triggering event to specify that. Now

31:58I've written a simple workflow that

32:00leverages these different types of

32:02triggers. You could see as I mentioned

32:04the push workflow could be triggered

32:06only on a specific branch pattern. So

32:08we've got example branch and then a wild

32:09card. So you can use glob patterns in

32:11those fields. pull request. The default

32:14if you don't specify a type of pull

32:16request event, it's going to be whenever

32:17one is opened, synchronized, or

32:18reopened. Uh and then you can also

32:20specify within a pull request event

32:22which paths you want to trigger on. And

32:25so this enables you to, as you'll see

32:27later on, filter down so you're only

32:29executing workflows relevant to a

32:31specific subpath within your repo. This

32:33is critical if you're using a monor repo

32:35that's going to have multiple services

32:36defined within it to not have wasteful

32:38execution of your workflows. You can see

32:41how this how the cron schedules are

32:43defined here with a cron string. So by

32:45specifying the string 00 star star star

32:48that's going to run at midnight UTC. So

32:50the zeroth minute of the zeroth hour

32:52every single day. That's what that

32:54means. And then we've seen the workflow

32:56dispatch already. That's just a manual

32:57trigger that you can execute either via

33:00the GitHub CLI or the web interface. In

33:03this example workflow, all I'm doing is

33:05taking the event that triggered the

33:06workflow and dumping that out to the

33:07terminal so that we can see all the

33:09different metadata that is associated

33:10with it that you can leverage from

33:12within the workflow as you perform your

33:14work. Now, specifically, let's take a

33:16look at the pull request and the path

33:18filtering to see how that would work.

33:20So, within my repo under the module 3

33:23subdirectory, I have this filters

33:25directory and within there we have an

33:27excluded file and an included file. My

33:30my paths filters should include markdown

33:32files but exclude text file. If I create

33:35a pull request that modifies the

33:36markdown file, it will execute this

33:39workflow. If I create a pull request

33:41that modifies only the text file, it

33:43will not execute it. So I've actually

33:44done that ahead of time. I've got these

33:46two pull requests here. This one we've

33:48modified the markdown file to include

33:51the paths filter. So I'm going to copy

33:53this branch.

33:59I'm going to push to get an update to

34:01that PR.

34:04And then if we go back here, this is

34:06workflow was triggered just a few

34:07seconds ago. We can go in and look at

34:10the event that triggered it. It's a big

34:12old JSON structure uh containing lots of

34:15information about the event that

34:16triggered it. So this is going to be

34:18things like the pull request number, uh

34:20the files that were modified, etc., etc.

34:22And so this is super useful as we go

34:24down the path of using these data to

34:26decide how our actions going to behave.

34:28Let's do the opposite and modify the

34:30file in that excluded filter. So if I go

34:33here and check out this one,

34:42let's just make an empty commit

34:46and push.

34:48Looking at the files changed, we've

34:50modified this text file on our branch.

34:54We've pushed that empty commit.

34:56However,

34:58no additional actions were triggered. If

35:00we go back here to the actions tab,

35:03no action was triggered. Now, why did

35:06this happen? We have prefix that

35:07exclamation point on line 15. When we

35:10modify a file that matches that pattern,

35:11we don't need to trigger this workflow.

35:13So that's how you can start to use these

35:14paths to understand how you can trigger

35:17and control when workflows are triggered

35:18for specific updates. As I showed, each

35:21of these events contains tons of

35:22metadata associated with it and that and

35:25you can tap into those data within your

35:26workflow itself. Just like with the pull

35:28request filter path filters, I can go

35:31ahead and make a branch that matches my

35:32example branch and say get checkoutb

35:38this will run workflow

35:44get push.

35:50We see that it triggered a run of my

35:52workflow based on that branch name.

35:56However, if I make a different branch

35:57name

36:04and I push that,

36:09we will not see an additional run

36:11because it didn't match any of the

36:12branch patterns to specified in that

36:13list. When we get to the capstone module

36:16of the course, you'll see how these are

36:18leveraged in practice across a variety

36:21of different use cases. The next core

36:22feature I want to touch on here are

36:24environment variables. These are

36:26variables within the execution

36:27environment and these can be scoped to a

36:29variety of different levels. Each of

36:30those different concepts that we talked

36:32about, we can have an environment

36:33variable that is shared across the

36:34entire workflow. We can have one that is

36:36shared only within a job or only within

36:38a step. And so you can see here I've

36:40specified one of each of those such that

36:43we can look at which are defined in

36:44which context. When we execute this that

36:46workflow var will be available in any of

36:48our different steps. Uh the job var will

36:51be available only in job number one. And

36:53the step var will be only available in

36:55job one step one. So let's go ahead and

36:57run this. That workflow is named

36:59environment variables. Run workflow.

37:05We'll click in here. We see jobs one and

37:07two. Because I didn't specify a needs

37:09key. These can run in parallel. Within

37:11job one,

37:14we can see all three of these are

37:17visible and print appropriately. If we

37:19look at job one, step two, we would

37:21expect the workflow and the job var to

37:23be defined. However, the step var is

37:25unset here.

37:27And then if we look into job two, now

37:31only the workflow scoped environment

37:34variable is going to be set. And the job

37:35and step variables which were scoped to

37:38job one are not set. This is how you can

37:41control environment variables set within

37:43your workflow itself. We'll look at in a

37:45little bit how to store environment

37:47variables from one step and persist

37:48those uh throughout the life of a job.

37:51This is within your job configuration

37:52itself.

37:54Now those environment variables were

37:55defined within our YAML file. We also

37:58can define things at runtime uh and pass

38:00data between steps and between jobs. Uh

38:03and so we can do this via outputs and

38:06inputs. Uh we also can do this via

38:08environment variables within a job

38:10itself. And so there's three kind of

38:12main things to showcase here. The first

38:14one is how to take some string and store

38:17it to an output and then how to consume

38:18that from within another step. And the

38:20way that we do that is we write to this

38:22file at the path specified by GitHub

38:24output. GitHub's going to populate that

38:26environment variable for us. We're going

38:28to echo fu equals bar. In this case,

38:32that double greater than sign is going

38:34to append to the end of that file. And

38:37now we can reference that in other

38:38steps. And so on line 26 we can say from

38:41the step with the id generate fu look at

38:43the outputs and use the fu output. So

38:46line 26 is going to output fu bar. For

38:50environment variables it's very similar

38:51but instead of writing to the github

38:52output file we write to the github end

38:55file within a job. We can then reference

38:58that as a normal shell variable. So like

39:00on line 25 we've got dollar sign fu. And

39:03then to pass things across jobs. So

39:05inter job we first need to put it as an

39:07output of the step like before. We then

39:10need to reference the job as an output

39:12of the job. So line 10 does that.

39:15And then in the consuming job we need to

39:18specify the needs key with the upstream

39:20job in it. And then finally we can

39:21reference it from that list of upstream

39:24jobs based on the name, the outputs and

39:27the key with which it's referenced. So

39:29if we go and run this, we'll see on

39:31lines 25 and 26, those two will both be

39:33set. But then on lines 34 and 35, only

39:36line 34 will be set. Whereas line 35

39:38with the environment variable, that does

39:40not persist across jobs. This workflow

39:43is named passing variables between jobs.

39:45We'll run it.

39:47As we expect, our producer is upstream

39:49of the consumer because we specified

39:51that needs key.

39:54Here we're generating those data. We're

39:55setting fu equal to bar

39:58and setting both our output and our

40:00environment variable. Now when we

40:01inspect the values, we can see they're

40:03both properly set to bar. In our

40:06consumer job, if we look at it, only the

40:09value which was passed from output to

40:11input persisted. That's because

40:14environment variables do not persist

40:15across jobs because they run in

40:17different compute environments. So you

40:18need to be explicit about which data

40:20you're passing from one job to another.

40:23Now the last feature that I want to

40:24touch on in this core features module

40:26are secrets and variables. So these are

40:28very similar to the environment

40:29variables that we saw before. However,

40:31these can be stored and managed at a few

40:33different levels. So you can store them

40:35either at the GitHub organization level,

40:37a repository within that organization or

40:39even a specific environment within a

40:40repository. So think about staging

40:42versus production might have different

40:43credentials for the deployment

40:45environment that you're going to deploy

40:46your application to. This allows you to

40:48do that. For sensitive values, database

40:50password or credential, those would go

40:52as secrets. And those you can only set

40:54within the UI, you can't actually read

40:55them back except within the context of a

40:56GitHub action. Uh for nonsensitive

40:59values that you want to be able to view

41:00and edit, those can be set as variables

41:03from within the UI. You can see those,

41:05update them, and consume them from

41:06within your actions. To set these, you

41:08go under the settings tab, and then

41:10under actions and secrets and variables,

41:12you can then populate them either for an

41:14environment or for the repository. You

41:16could do the same at the organization

41:18level to share secrets across different

41:20repos. And then for the the

41:22non-sensitive variables input, you click

41:25onto that variables tab and then you're

41:26able to specify them there. Within a

41:28workflow, you use that dollar sign

41:31double curly braces syntax. For secrets,

41:33it's going to be secrets dot and then

41:34the name of the secret. For variables,

41:36it's going to be varss dot and then the

41:37name of the variable. So within my repo

41:39under secrets and variables actions, you

41:41can see I've specified a staging and

41:43production secret. So these are two

41:46different values stored at the same key

41:47for different environments. I then also

41:49have a repository secret as well as some

41:52AWS secrets that we'll use later on.

41:55Finally in the variable side we have a

41:58staging and production environment

42:01variable nonsensitive and you can see

42:03the value specified here. And then we

42:05also have one at the repository level

42:07that will be shared across any

42:08environment. So if we go to our actions,

42:11scroll down to secrets and environments,

42:14click run,

42:17you can see I have two different jobs

42:18here. If we jump back to the definition

42:21on lines 8 and lines 26, I'm specifying

42:24the environment in which this is

42:25running. So the top job is going to use

42:27that staging environment uh secret and

42:29variable and the bottom job is going to

42:31use the uh production environment secret

42:33and variable.

42:35Let's click into the staging one and

42:38inspect the values of the job.

42:46Now you'll notice when we try to print

42:47out a secret value, GitHub automatically

42:50masks it using these asterisks. That's

42:53to prevent us from accidentally leaking

42:55our credentials or sensitive values into

42:56the logs of our jobs. Uh we also have

42:59seen we also see that it output the

43:01repository v variable and the staging

43:04variable. So if we go to the production

43:06job we'll see hopefully this repo

43:09variable will be identical but this

43:11should say this is the production

43:12environment variable value

43:15and that's exactly what we see. The repo

43:17variable was the same across these two

43:19different environment runs. However,

43:20within the job that specified the

43:22environment as production, we got the

43:24production specific value of that

43:25environment variable and that secret.

43:27Before we wrap up this module, I do want

43:29to call out a feature that we've already

43:30used a couple times, but I wanted to

43:32address it a little bit more explicitly,

43:34and that is contexts. So, within GitHub

43:36actions, there's all these different

43:37contexts that you have access to at

43:38runtime, and you access them using that

43:40dollar sign double curly braces syntax.

43:42So far, we've seen the needs and the

43:44steps context. We use those when passing

43:46data from one step to another or from

43:47one job to another. And then we just saw

43:49how to use the secrets and varss context

43:51to load those data into our runner. I've

43:53listed here at the bottom a number of

43:54additional contexts including the GitHub

43:57context that'll have things about the

43:58run and the repo state. The environment

44:00context will have all the environment

44:02variables set within the workflow job or

44:03step level. The matrix context which

44:05we'll use in the future to execute

44:07multiple copies of jobs. The job context

44:09which will have our current job status

44:10as well as some information about

44:12containers and services. The runner

44:13context which has info about the runner

44:15itself. And finally, the inputs context

44:17where you can provide inputs to your

44:18workflow and then use those at runtime.

44:20Now, we can move from those sort of

44:22basic core features of GitHub actions

44:24into some of what I would consider the

44:26more advanced features. Now, not all

44:28these are going to be difficult to use,

44:29but these are things that extend your

44:31ability to utilize the platform versus

44:33needing to use them right from the

44:35start. Like in module 3, these are still

44:37just a distilled version of each of

44:39these features, trying to capture their

44:41essence without getting bogged down too

44:43much in the weeds. We'll see how to use

44:45them for real world examples as we move

44:47on later in the course and into the

44:48capstone. The first feature that I want

44:50to highlight here are the runner types.

44:52Now, when I was describing the most

44:54basic hello world workflow, we still

44:56utilize the runs on field to specify

44:58what type of runner, but now we can look

45:00at the different types that are

45:01available. There's GitHub hosted

45:02runners. These are things like Ubuntu

45:0424.04, uh, Windows and Mac OS runners

45:07from GitHub. There's third party hosted

45:09runners. Now, these are going to be

45:11companies like namespace where you can

45:12utilize their infrastructure to execute

45:14your builds. And why would you want to

45:16do something like this? Oftentimes,

45:17they're able to offer significantly

45:19faster compute and storage at a reduced

45:22price relative to the hosted runners. It

45:23also opens up the possibility to utilize

45:26their infrastructure for things like

45:27faster caching, better observability,

45:29and improved multi-architecture

45:31container build experiences. The third

45:33category is self-hosted. So the actual

45:35runner agent is a open- source project

45:37which you can install into a server

45:39yourself or run in something like

45:40Kubernetes with the actions runner

45:42controller or arc project. There's also

45:44a really cool project called runs on

45:46which deploys a set of infrastructure

45:48into your own AWS account which can spin

45:50up ondemand EC2 instances for each

45:52runner job which can reduce the costs of

45:54execution even further while also

45:56keeping the data within your own VPC. By

45:58specifying a runner type, you're

45:59controlling which virtual machine image,

46:01the operating system, plus the

46:03dependencies which are going to be

46:04included in that environment, as well as

46:05the CPU and memory that are going to be

46:07available. You can see a number of

46:08examples here on the right, including

46:10the iuntu, Windows, and Mac OS runners

46:12from GitHub itself. There's also an

46:14option to execute your jobs within a

46:16container image. So, by specifying both

46:18a runs on and a container image, you're

46:20able to provide a container image with

46:22additional dependencies which might not

46:23be available in that base image. And

46:25then you can also specify a group or

46:27labels which you can apply to different

46:29runner types which allow you to control

46:30things like how many CPU cores or how

46:32much memory a particular runner might

46:34have. In the thirdparty hosted runner

46:35section, you can see a few examples from

46:37namespace. When you first create a

46:38namespace account, you'll have something

46:40like namespace profile default

46:41available. You can also append the ARM

46:4364 string to the end to get an ARM

46:46instance or you can provide your own

46:48custom image where you can install

46:50dependencies ahead of time to provide

46:52exactly the set of dependencies your

46:53build needs without the need to install

46:55or modify them with each run. Now,

46:57finally, for a self-hosted runner, you

46:59can name those runners anything you

47:00want. And so here, as an example, I've

47:02just named it my self-hosted runner

47:03name. I'm not going to do a deep dive on

47:05self-hosted runners. That could be a

47:06video in and of itself, and perhaps I'll

47:08do that. But within this course, you see

47:10me use a lot of GitHub hosted runners.

47:11And moving forward, you'll see me use

47:13those namespace runners quite a bit.

47:14Let's go ahead and jump over to GitHub

47:16and execute this workflow. I named this

47:18workflow runner types. We can click run.

47:21I have these three jobs at the top which

47:24are executing on GitHub infrastructure.

47:25I've got this one which is running on a

47:27GitHub virtual machine but inside of an

47:29Alpine container. And then finally, I've

47:31got this namespace VM. I'll show you. So

47:32if I go into my namespace account by

47:34logging in and go to profiles, this

47:37default one is provided out of the box

47:39as well as this ARM 64 image. Now these

47:42were two that I created custom with

47:43various dependencies pre-installed or

47:45with particular cache configurations

47:47enabled. To use this default runner, I

47:49just specify namespace profile default

47:52as my runs on field. If we click into

47:54one of these, we can validate that it is

47:55running what we expect. You can see

47:57hello from Linux x64, hello from Mac OS

48:00ARM 64, and this one since it's running

48:02inside that container is hello from

48:03Linux x64, but it shows us the container

48:06name of Alpine Linux. And finally,

48:09clicking into our namespace job, we can

48:10see it's also an x64 Linux runner.

48:14However, it's specifying the runner type

48:15as NSC for namespace cloud runner and

48:18then that identifier string. Now, if we

48:20look at the different runner types

48:21available, I mentioned that one of the

48:23reasons you might choose a thirdparty

48:24option is because they provide less

48:26expensive, more capable runners. As we

48:28can see here, this is a benchmark

48:30performed by runs on across many of the

48:32different providers, including GitHub,

48:34third party or self-hosted via runs on.

48:37As you can see, for these x64 runners,

48:39the namespace runners are at the very

48:41top in terms of performance and are also

48:43only half the cost of the hosted GitHub

48:45ones. I also added a circle for good

48:47developer experience because namespace

48:48provides some really nice features

48:49around developer experience just for

48:51using their runners. If we click into my

48:53namespace profile and I go to jobs, I

48:56can see all the jobs that have run. But

48:58if I go to insights now, I can start to

49:00see the execution timing for my job over

49:02time. I can filter down to a particular

49:04job and start to see how that

49:06performance is trending. If I click into

49:07a specific job, I can see CPU, memory,

49:10network, and storage performance within

49:12that execution as well as logs from that

49:14runner as it executed. And so I

49:15encourage you to check them out. There's

49:16a link in the description that will take

49:18you there. Definitely let them know that

49:19you found them through this video and

49:21say thank you for enabling me to create

49:22and distribute this content for free.

49:24Another feature that we haven't touched

49:25on yet is persisting data outside the

49:27context of their ephemeral runner. So by

49:29default, jobs are run in these ephemeral

49:31environments that are created and

49:33destroyed with the life cycle of the job

49:34itself. Artifacts give us a mechanism to

49:37persist data beyond that life cycle.

49:39There are two official actions provided

49:40by GitHub that we can use to both store

49:42and then consume artifacts. To upload

49:45artifacts, we use action/upload

49:47artifact. And to consume an artifact, we

49:49use the download artifact action. As you

49:51can see in my workflow here on the

49:53right, I'm going to create a text file.

49:55I then upload it as an artifact. And

49:58then in a downstream job, I'm able to

50:00download that text file and cat it out

50:01to the terminal. Artifacts also show up

50:03in the GitHub UI. So they can be useful

50:05for storing things like test results or

50:07other files that you might want to keep

50:09a record of across runs. We can jump

50:11over to GitHub and execute this. The

50:12workflow name is artifact.

50:15We've got our producing job and then our

50:17consuming job. So we took this string,

50:19stored it in an artifact.txt file,

50:23specified that is the file we wanted to

50:25upload. Then in our consumer, we

50:28specified which artifact we wanted to

50:30pull and then we catted that file to the

50:32terminal. If we go back to this workflow

50:34run, we can see in the UI, this is an

50:38artifact that was produced at runtime.

50:40We could download it. It's a zip file.

50:42If I open it up,

50:44here are the contents that we stored in

50:45that artifact. And this will persist

50:48such that if we needed to refer back to

50:49it for some reason, we could find the

50:51specific artifact associated with this

50:53workflow run in the future. Now, a

50:55similar but slightly different need to

50:57persist data across jobs is for caching.

50:59And so, again, jobs are ephemeral

51:01environments. So if we need to install

51:03or modify something within that job, we

51:05either need to do it every single time

51:07the job runs or we can use a cache to

51:09persist those data elsewhere and then

51:11restore them to avoid doing that

51:12repetitive work over and over. GitHub

51:14provides an official caching action

51:16action/cache. When you use that, data

51:19that you specify will be uploaded into a

51:21remote object storage that's going to be

51:22in Azure by default. And within GitHub,

51:25their cache is going to be capped at 10

51:26gigabytes. If you go over that 10

51:27gigabytes, it will evict stale data such

51:29that you and you will sort of have this

51:31rolling 10 GB window of your cache

51:33usage. As you can see from the workflow

51:35definition, we're going to start by

51:36attempting to restore the cache. If

51:38you've never run your workflow before,

51:40that would be a cash miss to start. Then

51:41on line 20, we can check if it was a hit

51:43or a miss. If it was a hit, then we can

51:45skip this step. If it was a miss, we

51:48will generate a file to then cache for

51:49future runs. We then have a step that

51:51says if it was a miss, we do want to

51:53populate that cache. And then finally,

51:55we're just outputting whether or not it

51:56was a hit and cadding that file to the

51:58Now, the types of things that you

51:59probably want to cache here, either

52:01things like your language runtime or

52:02tool chain that you'll need to build and

52:04execute your application or things like

52:06dependencies that you're downloading and

52:08including in your application builds.

52:09Let's go ahead and jump over to GitHub

52:11and see this workflow run. The workflow

52:12is named caching. We'll run it. Now, as

52:15you can see, this is the first time I've

52:17executed this workflow in a long time.

52:19So, any results that had been cached

52:20have been since evicted.

52:23It says cache not found.

52:26So we then created the file and stored

52:28it. Now if we go back and run it again,

52:31we should see a hit for that same key.

52:34Under the restore cache step, we see

52:36that it found our cache successfully.

52:38And then it was able to skip these two

52:39steps which which were conditional to

52:41only run if it was a cache miss. This

52:43showed how to cache specific paths or

52:45files within your runner. However, for

52:47many common languages and language tool

52:49chains, your cache configuration will

52:51depend on how those languages store

52:53dependencies. For example, when you've

52:55run the official setup node action, you

52:57can configure it to cache your npm

52:59dependencies as follows. For this

53:01example, I have just a super minimal

53:03Node.js project, which I can show in a

53:04second. We're running setup node with a

53:06specific version, and then we're

53:08configuring the cache of type npm and

53:10specifically telling it where within our

53:12repository the package.lock JSON file

53:15lives. This configures things so that we

53:16when we later run our npm install, we

53:18will automatically cache those node

53:20modules that get installed such that

53:22across runs as long as those

53:23dependencies don't change, we should see

53:25a significant speed up and avoid needing

53:27to redownload those with every

53:28execution. So here is the minimal node

53:30project within my package.json I just

53:32have a single dependency of leftpad and

53:35then my lock file similarly has that

53:36single dependency included. As you saw

53:38in the workflow from the slide, we're

53:40checking out the code. We're running

53:42setup node with our specific caching

53:43configuration. We're telling it where

53:45the lock file lives. That's how it

53:47generates an appropriate cache key

53:48before installing our dependencies and

53:50listing out the modules that have been

53:51installed. If we go back and look at

53:52those runs that we executed before, in

53:54the first run,

53:58there was no npm cache, but in the

54:01second run, we had a cache hit and we

54:05were able to download that dependency

54:07from our cache rather than needing to

54:08pull it from npm directly. So that's a

54:10node example. On the left you can see

54:12the documentation for how this would

54:14look with Go and each language is going

54:15to be slightly different in terms of

54:16where it stores its dependencies and how

54:18you should configure an appropriate

54:19cache key. Now caching is another thing

54:21that namespace does a bit differently.

54:23Uh so so far we've been using those

54:26object stored based caches where you're

54:28telling it a specific set of files and a

54:30specific cache key and it's a

54:32deterministic thing where you're going

54:33to upload those files and if you have a

54:35cache key hit you will pull them down at

54:36runtime. However, namespace takes a

54:38little bit different of an approach. You

54:39can configure what's called a cache

54:41volume and rather than upload and

54:43download explicitly from a object store.

54:46It's going to snapshot your volume after

54:48you've completed and then you can mount

54:50in a copy of that volume to each of your

54:52jobs to avoid that extra time of

54:54uploading and downloading these cached

54:56artifacts. It's going to be a bit less

54:57deterministic. However, because of the

54:59types of things that you're caching

55:00where you're often installing a set of

55:02dependencies over and over, usually that

55:04turns out fine. I created a simple

55:06example to sort of benchmark this where

55:09I have one job which creates a single

55:12very large file and uploads that to the

55:14GitHub actions cache as well as uses a

55:16namespace cache volume and then I have

55:18another job which generates thousands

55:21and thousands of very small files and

55:23does the same thing. As you can see,

55:25when you get a cache hit across them,

55:27the namespace cloud cache performs

55:29significantly better than the GitHub

55:30actions cache because you don't have to

55:32spend that time uploading and

55:34downloading those data. Because you're

55:35not specifying an explicit cache key,

55:38you could have a cache miss

55:39occasionally. But the penalty there is

55:41just a little bit of extra runtime.

55:42Whereas the benefit would be a

55:43significant speed up on nearly every

55:45single run. Let's take a look at how

55:46this workflow is defined. Here I'm using

55:48a set of tags that will allow me to get

55:51a namespace runner with the appropriate

55:53image type using four CPU and 16 GB of

55:56memory. And then I'm specifying the

55:58cache volume characteristics that I

56:01want. Here it's 20 GB. And I'm using

56:03this as sort of a unique volume type to

56:05separate my large test from my many

56:08test. I run the provided cache action

56:10step from namespace to set up my cache

56:13volume. I then check if the file exists

56:15that I'm looking for. If it doesn't

56:17exist, I generate a single large file

56:20and then I validate that the file exists

56:22afterwards. So if it was a cache hit,

56:25this should return true. If it was not a

56:26cache hit, it will get generated above.

56:28Now for the many test, it's similar. The

56:31only difference is that I use this small

56:33count environment variable specified

56:34above. So here I'm generating 100,000

56:36files, each of size 4,96 bytes, and then

56:41validating that those exist. The GitHub

56:43actions versions are pretty much

56:45identical. The only difference being

56:46that rather than using the namespace

56:48caching, I'm using the official GitHub

56:50actions caching. We can look at my first

56:52run of this workflow here where all of

56:54these caches miss. And you can see the

56:57single large file takes about 10 and 20

56:59seconds respectively on namespace and

57:01GitHub actions. And then the version

57:04where we generated 100,000 files takes a

57:06minute 43 and 2 minutes and 11. A lot of

57:08that time is spent generating those

57:10files and then uploading them to uh that

57:12object store cache. In this case, when

57:14we look at the next execution of this

57:16workflow, in this case, we had a cache

57:19hit for all of them, which is great. But

57:20we see the namespace instances took 3

57:23and 4 seconds respectively, whereas the

57:25GitHub actions cache took 28 and 12

57:27seconds respectively. And so, as you

57:29think about caching, this is a really

57:30unique approach that namespace has taken

57:32here. It does require adding a step to

57:33your workflow to set up that cache.

57:35However, it can pay huge dividends in

57:37terms of not performing repeated work

57:39and avoiding that upload download time

57:42that you need to use an object

57:44storebased cache. Moving on from

57:45caching, another critical feature that

57:47GitHub provides is the ability to scope

57:50what permissions your workflow has to

57:52the GitHub API. And so, by default,

57:54you're going to have contents and

57:56packages readonly permissions. The

57:58contents permissions will allow you to

58:00pull the code itself, which is going to

58:01be key for doing anything with your

58:03application. And then the packages is

58:05for the GitHub package registry. Uh

58:07you'll be able to read from there. There

58:09are additional permissions associated

58:11with all the different types of entities

58:12shown here on the left. And you can have

58:14either read, write or none. And the

58:16default is to have none for all of these

58:18except for contents and packages. I've

58:19written a workflow on the right hand

58:21side to just showcase how this works. In

58:23our first job, we have specified that we

58:25only have read permissions for pull

58:27requests and nothing else. I then design

58:29my job to both list the PRs in the repo

58:32as well as attempt to make an edit to

58:34one of those PRs by adding a label. That

58:37first run on line 16 will succeed. The

58:40second command on line 23 will fail

58:42because we don't have that right access.

58:44Now in the second job of specifying that

58:45we do have right access for the pull

58:47requests. Running that same command,

58:49we're able to successfully run the ad

58:51label command which will apply a

58:52documentation label to that specific PR.

58:54And just as a detail, the GitHub CLI

58:57uses the environment variable GH token

59:00for its authentication. That's why I'm

59:01taking that GitHub token provided by our

59:04runner and storing it in that

59:05environment variable for those different

59:06steps. Let's go ahead and see this run.

59:08Now I'll start by removing this label.

59:14Now we can go into actions and

59:16permissions,

59:17run the workflow. We can see the

59:20readonly PR job failed as expected. We

59:22were able to successfully list the PRs,

59:25but when we attempted to add that label,

59:26we got an error that the resource was

59:28not accessible via the integration. If

59:30we go to the readr PR that had the

59:32appropriate permissions, now when we add

59:33that label, this command succeeded. If

59:36we go to our pull request, that

59:37documentation label has been added back.

59:39So this gives us fine grain control over

59:41what within GitHub our workflows will be

59:43able to execute. In general, you should

59:45always scope the permissions to the

59:46minimum set that are required. Most

59:48workflows are going to need contents

59:49read access. Some are going to need

59:51packages read access and only if you're

59:53taking these other actions against these

59:55other entities would you want to specify

59:56additional permissions. So if that

59:58feature allows us to control access to

1:00:00GitHub systems, how do we control access

1:00:02to thirdparty systems? There's two

1:00:04primary mechanisms where we can

1:00:05authenticate to a third party system.

1:00:07The first of which is a static

1:00:09credential. Think of this as like an API

1:00:10key. This would be a longive credential

1:00:12that you would store in one of those

1:00:13GitHub action secrets we talked about in

1:00:15the previous module. It is less secure

1:00:17because it's a long live credential and

1:00:19so if that were to leak, someone might

1:00:20be able to use it. However, it is

1:00:22compatible with pretty much every

1:00:23platform. Any software platform you're

1:00:25accessing over the web is likely going

1:00:26to have a way to provide an API key or a

1:00:29static credential. Now, a better, more

1:00:31secure approach is what's known as an

1:00:32OIDC token. OIDC stands for Open ID

1:00:35Connect, and it is a short-lived

1:00:37credential which you will retrieve at

1:00:38runtime. Because of the fact that it's

1:00:40shortlived, it's more secure. If it were

1:00:42to leak after the fact, it would no

1:00:43longer be active and wouldn't matter.

1:00:45However, it does require that thirdparty

1:00:46service to support OIDC in the first

1:00:48place. I'm going to use AWS as an

1:00:51example of how we can use both of these

1:00:53mechanisms to authenticate. Uh the first

1:00:55one is going to use a static credential.

1:00:56While this course isn't about AWS, I can

1:00:58show you how I could generate a static

1:00:59key for AWS quickly within the console.

1:01:02And then the second approach will use

1:01:03that OIDC approach, which is a little

1:01:04bit more complex to set up, but not too

1:01:06bad. And it's really the way you should

1:01:08be doing this in production systems. So

1:01:10here I'm logged into an AWS account um

1:01:12and I have a user called the GitHub

1:01:15actions user. This user doesn't have any

1:01:17permissions really. So I just want to be

1:01:18able to authenticate as them and verify

1:01:20that I am authenticated in that way.

1:01:22However, under security credentials, you

1:01:24can go here to access keys. You can do

1:01:26create access key. Uh you can specify

1:01:29what type it is etc.

1:01:32and say GitHub action static key. Create

1:01:37access key. You can then copy these and

1:01:40paste them into the secrets interface.

1:01:42So if we go here under settings,

1:01:45secrets and variables actions and then

1:01:47we have AWS access key and secret key.

1:01:50So you would take those values from here

1:01:51and here uh and paste them in.

1:01:54Then within our workflow, we can use the

1:01:57official AWS actions configure AS

1:01:59credentials action and pass it the

1:02:01access key and secret access key as well

1:02:03as the region we want to authenticate

1:02:04to. And this will authenticate against

1:02:06that user using that static key. I show

1:02:08you this for completeness but as I

1:02:10mentioned really if it is available you

1:02:12should be using the OIDC approach. Here

1:02:14are the documentations on setting up

1:02:15that open ID connect with AWS. So

1:02:18specifically you have to add the OIDC

1:02:20provider within the AWS IM

1:02:22configuration. We can click into these

1:02:23docs and follow these steps. The way

1:02:25that you do that is under IM identity

1:02:28providers. Click add provider

1:02:31open ID connect. It then gives you the

1:02:33provider URL and audience.

1:02:37This is the provider URL. This is the

1:02:39audience.

1:02:41We then need to specify an IM role that

1:02:43our GitHub action will be able to

1:02:44assume. So I can go back over here. I've

1:02:47already done this which is why I didn't

1:02:48create that. But you can see my provider

1:02:49here

1:02:51with my audience. Now under roles

1:02:55I have this GitHub actions role that

1:02:56I've created. And in order to assume

1:02:59this role, we need to add a trust

1:03:01relationship

1:03:03which says we are federating access to

1:03:06this role based on the OIDC provider.

1:03:08This is pointing to that provider that

1:03:10we just specified. I'm going to give it

1:03:11the ability to assume my role with the

1:03:14audience that I specified for that

1:03:15provider. And then finally, this is how

1:03:17I can lock down access to a specific

1:03:19repo or user. So in this case, only

1:03:21repos that I own will be able to access

1:03:24this role. And so with those things set

1:03:25up, the OIDC identity provider as well

1:03:27as this role with the appropriate trust

1:03:29policy, I can now run the same configure

1:03:31advis credentials action, but instead of

1:03:34needing to pass it that secret access

1:03:36key, I can just specify the role that I

1:03:38want to assume. There is one important

1:03:40note here and that is this 21. The ID

1:03:42token permission must be set to write in

1:03:45order for us to successfully request a

1:03:47JWT and use it for that OIDC

1:03:49authentication. And so it's not that

1:03:51much more complex, but it's much more

1:03:52secure. So if you're going to

1:03:54authenticate to a system which does have

1:03:56this support you should use the OIDC

1:03:57approach if not you can always fall back

1:03:59to a static credential as shown above.

1:04:01Let's go ahead and run this workflow

1:04:03just to showcase that it works. It's

1:04:04called third party off run workflow run.

1:04:10We successfully authenticated here and

1:04:13we successfully authenticated against

1:04:15our role here.

1:04:18Now the final feature set that I want to

1:04:20highlight in this section is matrix and

1:04:22conditionals. So uh matrix provides us

1:04:25the ability to run multiple copies of a

1:04:27job with different input configurations.

1:04:29And then conditionals allow us to

1:04:31specify an if statement that allows

1:04:33steps to either run or not run or jobs

1:04:35to run or not run based on the value of

1:04:38variables within our workflow. Now

1:04:39finally concurrency controls how

1:04:42multiple runs of the same workflow

1:04:44should be handled. And so if we're

1:04:45triggering the same workflow uh let's

1:04:46say based on multiple commits to our

1:04:48repo allows us to specify which of those

1:04:51runs should be grouped together and then

1:04:52within a group should you cancel those

1:04:54runs or allow them to continue

1:04:55executing. This can avoid wasted compute

1:04:58for runs which are meaningless if

1:04:59they've been superseded more recent

1:05:01code. To highlight these I created a

1:05:03simple workflow that has two jobs. The

1:05:05first of which is a matrix job. And so

1:05:07under that strategy matrix key we can

1:05:10provide a set of inputs. Here we have

1:05:12number one and two as well as letter

1:05:13ABC. And then GitHub actions will take

1:05:15all of those combinations. So we'll have

1:05:171 A, 1 B, 1 C, 2 A, 2 B, 2 C. And then

1:05:20finally we have this exclude key which

1:05:23says run all six of those combinations

1:05:24except don't run 1 C. So we should see

1:05:27five different jobs running in parallel

1:05:29executing those different combinations.

1:05:31To highlight the conditional aspect,

1:05:33also within step two, I've added this if

1:05:35statement saying if matrix number equals

1:05:372 and matrix letter equals C, skip that

1:05:40job. So we'll see five jobs running in

1:05:42parallel and within one of those jobs

1:05:44we'll see this step specifically skipped

1:05:46to highlight our concurrency setting

1:05:48I've grouped by GitHub workflow. So

1:05:50that's the workflow name as well as the

1:05:52GitHub ref. So that's going to be like

1:05:54my branch or my tag such that if we push

1:05:56to the same branch multiple times while

1:05:58the old job is running it will cancel

1:06:00that older job. This is why I've

1:06:02included that sleep job at the bottom so

1:06:03the execution takes long enough to give

1:06:05us time to come back issue a new commit

1:06:08and force this to cancel the old run. So

1:06:10let's go ahead and see this in action.

1:06:11We'll go to matrix and conditionals.

1:06:13We'll start by triggering one here. That

1:06:16first one is

1:06:18we see those five jobs executed 1 A, 1

1:06:20B. We skipped 1 C, remember? Now we have

1:06:232 A, 2 B, and 2 C. But if we click into

1:06:252C based on that conditional I had

1:06:27specified there, we're going to skip

1:06:29that specific step. Now let's take a

1:06:31look at how the concurrency works. So

1:06:33this one is still running because that

1:06:35sleep job is specified to sleep for 100

1:06:37seconds. We'll trigger another run of

1:06:38this workflow.

1:06:41And because that concurrency group is

1:06:43going to match because it's the same

1:06:44workflow and it's off of the main

1:06:46branch, it's waiting for GitHub to then

1:06:48cancel this older run. We see status

1:06:50canceled.

1:06:52And now the newer run will take over and

1:06:54execute. I kind of sped through these

1:06:56features, but these are really powerful

1:06:58features that allow us to control the

1:06:59execution of the workflow at runtime.

1:07:01And we're going to leverage these

1:07:02heavily as we move into the capstone

1:07:04project and start to do things within

1:07:06our monor repo to fan out jobs across

1:07:08the different services and only execute

1:07:09the jobs and steps which need to be run

1:07:11for each of them. Now, so far we've

1:07:13mostly focused on our workflows and all

1:07:15the features that GitHub actions has for

1:07:17authoring those. Now, we're going to

1:07:18spend the next few modules looking at

1:07:19individual actions. So, if you think

1:07:21back to module 3 where I showcased the

1:07:23different types of steps you can write,

1:07:24a step can either be an inline bash

1:07:26script, an inline Python script, or it

1:07:29can be an action. And so an action is

1:07:30going to be a separate application which

1:07:33runs as a step within one of your

1:07:34workflows. One of the key features that

1:07:36differentiates GitHub actions from some

1:07:38of the other competitors is the huge

1:07:40public marketplace. And so in this

1:07:41module, we'll take a look at that public

1:07:42marketplace and how to utilize actions

1:07:44that exist there. If you go to

1:07:46github.com/marketplace

1:07:47and then search for type actions, you'll

1:07:50see a listing of all the public actions

1:07:51that are available there. You can then

1:07:53sort them by various features and search

1:07:55for the type of action that you want.

1:07:57I'll go to my browser and navigate there

1:07:58now. So, here I am on the GitHub actions

1:08:00marketplace. As you can see, there's

1:08:02lots of different actions available. If

1:08:03I scroll to the bottom, there's over 500

1:08:04pages of them. Uh, we've already used

1:08:06some of these. For example, the checkout

1:08:08action is the official action from

1:08:09GitHub to check out your code from your

1:08:11repository. To use any action within

1:08:13your step definition, you'll have the

1:08:15uses key and then a path to the repo

1:08:17where it lives. In this case, this is

1:08:19the actions organization and the

1:08:21checkout repo. So, while we can see it

1:08:23on the marketplace, we can also see the

1:08:25git repo associated with this. If we go

1:08:26down here and click view source code,

1:08:30you'll notice that because that was an

1:08:32official action from GitHub, it has this

1:08:34blue verified check mark. Let's imagine

1:08:36our project was using Cypress for

1:08:38endtoend tests. Let's search for

1:08:39Cypress. There's this action from the

1:08:41Cypress organization itself, as well as

1:08:43a number of other actions for doing

1:08:44various things with Cypress. Let's click

1:08:46in here. We can see they're going to set

1:08:48up things like installing our

1:08:49dependencies, handling caching. So

1:08:51rather than need to author all this

1:08:52ourselves, we could likely tap into this

1:08:54action, add it to our workflow with just

1:08:57a couple of lines, and get our Cypress

1:08:59test running within GitHub. Just that

1:09:01easy. Now, as I look at these third

1:09:03party actions, there's a number of

1:09:05signals I'm using to decide if I want to

1:09:07use it or not. In general, I'm going to

1:09:09assess it like any open source

1:09:10dependency that I might pull into my

1:09:12application. The number one criteria is,

1:09:14does this action do what I want it to

1:09:15do? Is it providing value to me? and is

1:09:18that value worthwhile enough for me to

1:09:20want to use it instead of authoring that

1:09:21capability myself. In terms of the

1:09:23quality and trustworthiness, there's a

1:09:24number of things you can look for.

1:09:25There's that blue check mark which means

1:09:27that GitHub has verified the identity of

1:09:29the organization or user who has

1:09:31authored that action. That can be one

1:09:33signal of a a more trustworthy action.

1:09:35Now, not every action that you want to

1:09:36use is going to be verified in this way,

1:09:38but that's just one signal you can use.

1:09:40The number of stars, just like an open

1:09:41source project, shows how popular a

1:09:43project is. The higher the number of

1:09:44stars, the more likely it is that lots

1:09:46of people are using and verifying the

1:09:48capabilities of that action as

1:09:50described. And then finally, is this an

1:09:51active project? If you look into the

1:09:53repo, as I showed you, as you click into

1:09:55that repo and look at the commit

1:09:57history, are there commits in the last

1:09:59week or few weeks or has it been

1:10:01stagnant for many years? I'm much more

1:10:02likely to use an action which has an

1:10:04active history and it seems that the

1:10:06authors are continuing to update and

1:10:08address potential issues as they may

1:10:09arise. Early in the course when I used

1:10:12thirdparty actions, you saw that I

1:10:13tagged it with the specific commit hash

1:10:16rather than a version. Now any of these

1:10:18four syntax will work. On line two, it

1:10:20would just use the latest version

1:10:21available. On line three, it would use

1:10:23the latest major version 4. Line four is

1:10:26going to use that specific git tag of

1:10:284.2.2. But then line five, I get a

1:10:30specific commit within that repo. This

1:10:33is important because these are third

1:10:34party dependencies. The only way within

1:10:37GitHub actions to ensure that you're

1:10:38running the exact same version is to pin

1:10:40to the commit hash. It may seem like

1:10:42pinning to a specific git tag is

1:10:43sufficient. However, there have been

1:10:45incidents where a malicious actor took

1:10:47over a repo where a GitHub action lived,

1:10:49wiped all of those git tags, and pushed

1:10:51a malicious commit, and then rettagged

1:10:54every single historical tag to that

1:10:55malicious commit to exfiltrate secrets.

1:10:58That's why I always recommend that you

1:10:59should pin to the specific commit hash

1:11:00because that can't be modified after the

1:11:02fact and so it guarantees you will keep

1:11:04that same version and you wouldn't be

1:11:05impacted by something like that. I also

1:11:07add a comment with the tag that that

1:11:10commit points to just to make it clear

1:11:11to future readers which version or

1:11:13release of that action is running. Now

1:11:15I'll quickly highlight a handful of

1:11:17popular actions that I have seen used

1:11:19broadly across the projects that I've

1:11:20worked on. As I mentioned, GitHub itself

1:11:22provides a number of official actions.

1:11:24These are things that most every repo is

1:11:26going to leverage. things like checking

1:11:27out your code, uh caching as we saw in

1:11:30the previous module, using that artifact

1:11:32upload and download to store artifacts

1:11:34from within a workflow run. And then

1:11:35this last one, GitHub script, provides

1:11:37an interface to very easily make calls

1:11:39to the GitHub API via action that takes

1:11:42as an input an an asynchronous

1:11:44JavaScript function. So if you need to

1:11:45do something uh to interact with some

1:11:47GitHub entity, like maybe add a comment

1:11:49to a PR based on the results of your

1:11:51workflow, the GitHub script action is

1:11:53one easy way to do that. Another

1:11:55category of actions that are very

1:11:57popular and are used in almost every

1:11:58project that I've worked on are actions

1:12:00to install the runtimes and dependencies

1:12:02that you may need for your continuous

1:12:04integration workflows. These are three

1:12:06examples which all come from the

1:12:08official GitHub organization. The first

1:12:10one is to set up Node.js. The second one

1:12:11to set up Go and the third one to set up

1:12:13the Java development kit. These are

1:12:15going to contain utilities for things

1:12:16like configuring caching appropriately,

1:12:19making sure that you have the right

1:12:20version of your language, and including

1:12:22the common software that you would need

1:12:23in that language tool chain. Another

1:12:24popular project is the super llinter.

1:12:26This is an application that has linting

1:12:28capabilities across a huge variety of

1:12:31different languages. So, you can use

1:12:32this single action to lint across any of

1:12:35the languages that you're using within

1:12:36your project, which can be quite

1:12:37convenient. And then just a few more

1:12:39here that I see used all the time are

1:12:40building and pushing your container

1:12:42images. There's an official action as

1:12:43well as one from Docker. This will

1:12:45include things like authenticating to

1:12:46your registry, passing it the

1:12:48appropriate tags and telling it where

1:12:51your build configurations live to then

1:12:53go off and build and push your container

1:12:55images. These also often times contain

1:12:57utilities for handling

1:12:59multi-architecture builds. And then

1:13:00finally, for authenticating third party

1:13:02systems, many organizations will provide

1:13:04an action that makes that much easier. I

1:13:06showcased this with AWS in the previous

1:13:08module, but Azure and GCP also provide

1:13:11their own authentication actions. And so

1:13:13rather than needing to download the

1:13:15appropriate CLI and manually pass in the

1:13:17credentials, these are configured to

1:13:19make that much easier to streamline your

1:13:21usage of those platforms from within a

1:13:23GitHub actions workflow. Throughout the

1:13:25rest of the course, you'll see me

1:13:26actually use a number of these actions

1:13:28as we build out the various workflows

1:13:29for our capstone project. In the

1:13:31previous module, we saw how to consume

1:13:33these marketplace actions. Now, let's

1:13:34take a look at how to author our own

1:13:36firstparty actions. There's a handful of

1:13:38mechanisms within GitHub actions that we

1:13:40can use to write and reuse our logic

1:13:42across workflows. The four that I'm

1:13:44going to be covering here are composite

1:13:45actions, reusable workflows, JavaScript

1:13:48and TypeScript actions, and then

1:13:50container actions, which actually allow

1:13:51you to write your actions in any

1:13:52language that you'd like. A composite

1:13:54action is the easiest way to bundle up

1:13:56logic that you want to reuse across

1:13:58multiple workflows or across different

1:13:59jobs within the same workflow. All you

1:14:01need to do to create a composite action

1:14:03is create an action.yaml file. This file

1:14:05is going to look very similar to the

1:14:07workflow files that you're used to,

1:14:08except it's going to optionally include

1:14:10a set of inputs, a set of outputs and

1:14:12then a list of all the steps that you

1:14:14want to execute within it. Once you have

1:14:15that composite action defined to consume

1:14:17it, you use the uses syntax and pass a

1:14:19relative path to that composite action

1:14:21within the repo. In this example, I have

1:14:23a very simple hello world composite

1:14:25action. It's going to do two things.

1:14:27It's going to take an input string of

1:14:28who to greet and print that out to the

1:14:30console. It's then also going to

1:14:32generate a random number and provide

1:14:33that as an output to the action. To

1:14:35showcase utilizing this, I've written a

1:14:37simple workflow on the right hand side

1:14:38which takes this composite action and

1:14:40consumes it in two separate jobs with

1:14:42slightly different input strings. And

1:14:43then we also echo out that random number

1:14:45just to showcase that they're going to

1:14:47be different. It's important to note

1:14:48that we do have the actions checkout

1:14:49step there on lines 10 and lines 23.

1:14:52This is what's going to pull down the

1:14:53source code where that action.l ammo

1:14:54lives and allows us to use it within our

1:14:56workflow. Let's go to GitHub and run

1:14:58this workflow to see it in action. I

1:14:59called my workflow composite action

1:15:00demo. Run workflow.

1:15:03We've got our two jobs. In our first

1:15:05job, we can see that we input who to

1:15:07greet as from composite action in hello

1:15:10world 1. And we got that echoed out to

1:15:11our terminal. And then we can see that

1:15:13the random number passed as an output

1:15:14from our composite action was 13829.

1:15:17If we go to the second job, we ran our

1:15:19composite action, but we passed a

1:15:21different input string with this hello

1:15:22world 2 that was echoed out to the

1:15:23terminal and our random number is

1:15:26different with 10,129.

1:15:29Now, in the repo for the course, I

1:15:30stored the action in the directory

1:15:32associated with this module. Normally

1:15:33though, I would store actions like this

1:15:35under the.github/actions

1:15:37directory, which is a nice convention so

1:15:38that you can go there and find all the

1:15:40actions associated with a particular

1:15:41repo. Now, the next mechanism for

1:15:43reusing logic across workflows is what's

1:15:45known as a reusable workflow. Now

1:15:47technically this isn't a GitHub action.

1:15:48It is a workflow and it runs as a job

1:15:50within another workflow rather than as a

1:15:52step. However, the reason you use a

1:15:54reusable workflow to take logic that you

1:15:56want to share across different

1:15:57executions of a workflow is quite

1:15:58similar in nature to these others and

1:16:00which is why I included it in this

1:16:01section. On the right hand side, you can

1:16:02see I've defined the source for this

1:16:04reusable workflow. This is going to use

1:16:05the same approach as all the other

1:16:06workflows we've seen thus far. However,

1:16:08the key distinction here is on line four

1:16:10and it uses that workflow call trigger

1:16:12which is what indicates that it is a

1:16:13reusable workflow. is going to be called

1:16:16from another workflow. Like our

1:16:17composite action, we're going to

1:16:18optionally have a set of inputs and then

1:16:20there on line 13, we can define which

1:16:22secrets need to be passed into our

1:16:23workflow. It is important to note you

1:16:24can only pass repository or or level

1:16:27secrets in this fashion. If you want to

1:16:29access an environment secret on the

1:16:30consumer side, you need to specify that

1:16:32environment and then also indicate that

1:16:34you want to inherit those secrets. An

1:16:36example of this is in our caller

1:16:38workflow there on the left. So this

1:16:40caller workflow is going to execute two

1:16:42copies of this source workflow. The

1:16:44first one we're running with that

1:16:45staging environment and we're telling it

1:16:47that we want to inherit the secrets from

1:16:49our environment. And in the second one,

1:16:51because we haven't specified that we'd

1:16:52like to inherit, we will not pick up any

1:16:54secrets from the production environment

1:16:56and we'll only have access to that

1:16:57explicit example repository secret that

1:16:59we're passing directly. There's also two

1:17:01ways to reference these. On line 9, this

1:17:03is similar to with the composite action

1:17:05where we have a relative path to the

1:17:06workflow in our repo. This will follow

1:17:08along. We'll use the current commit

1:17:10within a repository as the source

1:17:12definition. Whereas on line 17, we're

1:17:14passing it an explicit git reference to

1:17:16the repo and the commit hash, which

1:17:19allows us to pin it to this particular

1:17:20version and have more control over when

1:17:22it upgrades. Let's go to GitHub and run

1:17:24a copy of this caller workflow. Even

1:17:26though both of these are workflows, we

1:17:27wouldn't call that source workflow

1:17:29directly. Instead, we want to run the

1:17:30caller workflow, which will run our

1:17:32source workflow as jobs within it. So,

1:17:35I'll navigate to reusable workflow

1:17:36caller. Run workflow.

1:17:39We get the two copies of our job.

1:17:42I'll click into the staging one and

1:17:44remember in this case I told it to

1:17:45inherit the secrets that are available

1:17:47and so this example environment secret

1:17:49is defined although it's masked if we

1:17:51click into our production environment

1:17:53job in that one I did not tell it to

1:17:55inherit the secrets and so by default it

1:17:57will not inherit my environment secrets

1:17:59the repository secret is available there

1:18:01because I passed it explicitly so when

1:18:03would I want to use just a normal

1:18:05standard workflow versus a composite

1:18:07action versus a reusable workflow I made

1:18:10this little flowchart to showcase how I

1:18:12think about these things. The first

1:18:14question I would ask is, do you need to

1:18:16reuse this logic across multiple repos

1:18:18and or workflows? If the answer is no,

1:18:19you can just use a standard workflow.

1:18:21There's no benefit to moving this logic

1:18:23into one of these other approaches. If

1:18:25the answer is yes, then you need to

1:18:26further ask yourself, do you need to

1:18:28enforce standardization across the

1:18:30entire workflow itself? If the answer is

1:18:32yes, you want to go with a reusable

1:18:33workflow where you define that entire

1:18:35workflow and the only modifications are

1:18:37going to be the input values. If you

1:18:39don't need to enforce that level of

1:18:40standardization, a composite action is a

1:18:43slightly lighter weight and more

1:18:44flexible approach where you can bundle

1:18:45up just a subset of the logic while

1:18:48still avoiding copy pasting across a

1:18:49bunch of different places. As you think

1:18:51about your organization's needs and

1:18:53specific continuous integration

1:18:54workflows, hopefully this helps you

1:18:55decide what logic should live where.

1:18:57Moving on to the third type of action,

1:18:59we have JavaScript and TypeScript

1:19:00actions. Now, this is the type that

1:19:01GitHub action supports most natively and

1:19:04many of the actions that you encounter

1:19:05on the marketplace or otherwise will be

1:19:07of this type. GitHub provides an npm

1:19:09package called actions core that you

1:19:11will install as a dependency into a

1:19:12JavaScript or TypeScript project. You

1:19:14can then import that and that will

1:19:15contain many different utilities for

1:19:17interacting with GitHub and GitHub

1:19:19actions. Just like with the composite

1:19:20action, you'll include an action.yml

1:19:22file that defines the metadata for your

1:19:24action including optional inputs and

1:19:26outputs. And then you'll notice at the

1:19:27bottom there in the under the runs key,

1:19:29you'll specify which runtime to utilize.

1:19:32In this case, it will be a Node.js

1:19:33runtime. And then you need to specify

1:19:35where your main function lives. Now,

1:19:36regardless of whether you're authoring

1:19:37your action in JavaScript or TypeScript,

1:19:39you must package it as JavaScript. This

1:19:41means that if you're writing as

1:19:42TypeScript, you're going to have a build

1:19:43step where you turn that TypeScript and

1:19:45bundle it as JavaScript for consumption.

1:19:47GitHub provides a template repo for both

1:19:49the JavaScript action as well as a

1:19:51TypeScript action. I've taken both of

1:19:52these and added them as subm modules to

1:19:54the course repo to showcase how they

1:19:56work. There's a third option of writing

1:19:57a JavaScript action with no build step.

1:20:00You check in all your dependencies as

1:20:01node modules, but I wouldn't suggest

1:20:02that. I would generally recommend going

1:20:04with a TypeScript action which is going

1:20:05to have that build step which is going

1:20:07to transpile your TypeScript into

1:20:08JavaScript and bundle all those

1:20:10dependencies alongside your action code.

1:20:13This will be more reliable and allows

1:20:14you to utilize types to make it easier

1:20:16to maintain and validate your action as

1:20:18you develop it. I'll jump to my code

1:20:19editor and show you what this looks like

1:20:21under module 6 JavaScript actions

1:20:23TypeScript action with build. I've added

1:20:25a copy of that template repo that I was

1:20:27just showing as a subm module to the

1:20:28course repo. We can take a look at the

1:20:30action.yaml YAML which is just like I

1:20:31showed on the slide. Here we're running

1:20:33NodeJS20 and my main function lives in

1:20:35this distindex.js.

1:20:37Now you'll notice I have my source files

1:20:39here written in TypeScript. The majority

1:20:40of my logic lives in this main.ts which

1:20:43is exported and run from within my

1:20:44index.ts and my build step is defined

1:20:48within my package.json. So under

1:20:50scripts, these are all scripts that were

1:20:51provided in that template repo. The

1:20:53build step is defined here in this

1:20:54package command which is going to use a

1:20:56tool called rollup to take my TypeScript

1:20:58and all the dependencies associated with

1:20:59my project and build them according to

1:21:01my configuration defined here. It's

1:21:04taking as my primary input that index.ts

1:21:06file and then providing as my output in

1:21:09the disk directory an index.js file with

1:21:11a source map using ES modules. Let's

1:21:13take a look at this main function and

1:21:15maybe make a slight tweak to show you

1:21:16what the process. As I noted, we're

1:21:17importing this actions core npm package

1:21:20from GitHub with methods like

1:21:21core.debug. So this is a debug log and

1:21:23core setoutput where we can set the

1:21:25output of our action step. Let's add

1:21:27another log here.

1:21:29It says hello this is another info level

1:21:31log. I'll save it. However, this only

1:21:33exists in the TypeScript file currently.

1:21:35Let's go ahead and bundle our code so

1:21:37that will get propagated into the

1:21:39necessary JavaScript. For that I can do

1:21:40npm run bundle.

1:21:43If I look at the git diff, here's the

1:21:45change I just made to the TypeScript

1:21:46file. But then because we bundled it, we

1:21:48now have a modification to our generated

1:21:50JavaScript file and to the source map. I

1:21:52can then commit these to the repo.

1:21:55Then update the subm module reference to

1:21:57be for that latest commit.

1:22:00And now let's go ahead and run that. Now

1:22:02this JavaScript actions workflow

1:22:04contains three jobs. One using a no

1:22:05build JavaScript action which exists in

1:22:07the repo. You can check it out, but as I

1:22:08mentioned, I wouldn't use that approach.

1:22:10Another one using a JavaScript action

1:22:12that does have a build step. And then

1:22:13thirdly, the TypeScript action which is

1:22:15referencing the project which I just

1:22:16modified. And so this is the one that

1:22:17we're going to want to look at. We go to

1:22:18actions, JavaScript actions, run

1:22:21workflow.

1:22:23That info level log line that we added

1:22:25now shows up here. Now, the last type of

1:22:26action that I'll cover here is a

1:22:28containerbased action. Because a

1:22:29container can leverage whatever runtime

1:22:31or language we'd like. So if our team is

1:22:33a bunch of engineers who are experts in

1:22:35Python, but don't really write

1:22:36TypeScript ever, we may want to author

1:22:38our actions accordingly. There also

1:22:39could be dependencies or packages that

1:22:41we want to pull in to perform some type

1:22:43of work that have a much stronger

1:22:44ecosystem within a particular language.

1:22:46Here within the action.yamel you can see

1:22:48on line 12 rather than using the Node.js

1:22:49runtime we're specifying that it's using

1:22:51Docker. And then for the image you can

1:22:53either specify Docker file which will

1:22:54build the Docker file each run or you

1:22:56can specify container image at a

1:22:58particular tag. Option A is great for

1:22:59testing and validating because it will

1:23:01dynamically build the current state of

1:23:02the repo. However, needing to rebuild

1:23:04the action image with each build is a

1:23:06bunch of wasted effort and time for

1:23:09production workflow that you care about

1:23:10speed and performance. You'll likely

1:23:12want to have a process by which you

1:23:13build that container image and push it

1:23:15to your registry and reference it

1:23:16directly. The process by which we

1:23:18extract things like inputs into a

1:23:19container image is a little bit clunky.

1:23:21As you see here, this action has the

1:23:22input who greet which is going to be a

1:23:24string. And within Python, I either need

1:23:27to load it from this badic environment

1:23:28variable that GitHub is populating,

1:23:30which would be input underscore and then

1:23:31the name of the input in all caps snake

1:23:33case or I can pull it out of the args

1:23:35list using something like cis.orgv.

1:23:37Also, there's no official GitHub package

1:23:40for languages other than JavaScript. So,

1:23:42in order to interact with GitHub

1:23:44actions, I end up having to print these

1:23:46magic strings to console using things

1:23:48like colon. Notice they're on line 18

1:23:50rather than being able to use a specific

1:23:52method from that core package that we

1:23:54had in JavaScript. To write to an output

1:23:56is shown here on line 21 where I need to

1:23:58open the file that is at that GitHub

1:24:00output path and then append any

1:24:02information to it similar to how we did

1:24:04before when writing to it in bash. Now,

1:24:06finally, I need to bundle this up in a

1:24:07Docker file, which will vary based on

1:24:09the language that I'm writing my action

1:24:10in. In this case, because I don't have

1:24:12any dependencies, I'm simply starting

1:24:14from the Python base image, copying in

1:24:16my entry point Python script, and then

1:24:18setting the entry point that will run

1:24:20when the container is executed. If I did

1:24:21have additional dependencies, this

1:24:23Docker file would need to account for

1:24:24that by doing things like copying in a

1:24:25requirements file, running a pip install

1:24:27or whatever other package manager I

1:24:29might be using like poetry, etc. Now

1:24:31within the repo under module 6 container

1:24:34actions I have three container actions

1:24:36showed here. One is based on the

1:24:38template that that GitHub provides for a

1:24:40container action. Now this action is

1:24:42just using a bash script bundled up in a

1:24:44docker file. It's a little bit

1:24:45contrived. If you were just going to use

1:24:47bash, you would likely put that directly

1:24:49in your workflow. However, it shows how

1:24:50you can wrap things up inside a

1:24:52container image. I then also have the

1:24:53Python container that I was showing on

1:24:54the slide. In order to showcase these, I

1:24:56wrote a simple workflow with three jobs.

1:24:58The first one is calling that shellbased

1:25:00container action that is a subm module

1:25:01of this repo. You can see here I'm

1:25:03referencing that path. The second one is

1:25:05running a nearly identical copy of that

1:25:07shellbased container action. However,

1:25:08it's referencing a pre-built image. So

1:25:10if we look at the make file here, rather

1:25:12than image docker file, it's referencing

1:25:15this public container image sid palace

1:25:17shell container action add a specific

1:25:19version which will avoid the need to

1:25:20build that image with each execution. In

1:25:22order to build and push that container

1:25:24image, I just have this simple make

1:25:25file. I'm just running a docker build

1:25:27and a docker push to DockerHub. Now the

1:25:29third job is executing that Python based

1:25:31container image also using the Docker

1:25:33file approach. So it's going to build it

1:25:35dynamically. But we should see all three

1:25:37of these run and despite their different

1:25:38configurations basically the same way.

1:25:40So I can go to actions container actions

1:25:43run workflow.

1:25:47The instance of our shell container

1:25:48where we use that public container image

1:25:50is done after 5 seconds. Whereas the one

1:25:52where we had to build the container

1:25:53image first took nearly double that. If

1:25:55I click in here, we can see the culprit