GitHub Actions

[00:00:00]
>> There is going to be a little bit of a choice time here. But if you don't wanna make a choice, you can actually just, I would say fork the repo that we're using, or grab any repo you want that has tests, cuz it really doesn't matter. You can even create React app and just put a test in.

[00:00:17]
This part doesn't matter, but what we're gonna do is look, again, as our segue, we talked a little bit about unit testing. We could go into component testing, we could go into playwright testing, but as a palette cleanser, to talk about something is not testing. We're going to look at kind of setting up our first GitHub Action, right?

[00:00:38]
GitHub Action is basically a CI/CD process that is built into GitHub. If you've ever used anything like Travis CI or CircleCI, or as I joked earlier, if you've ever had the pleasure of using Jenkins, that's a joke, nobody's ever said that and meant it. You've used some amount of CI/CD before, basically, it runs your processes for you and usually breaks your build if something fails, usually your tests.

[00:01:10]
If it's Jenkins, it could be any number of reasons why Jenkins failed. Some of those might have to do with the thing you need to change. Some of it could just be like the way that the moon was in relationship to Saturn. But GitHub Actions, all of this applies to whatever you use, right?

[00:01:25]
GitHub Actions is just being the lowest common denominator, which is, we're gonna push this to GitHub, there is GitHub Actions. You might choose to use GitHub Actions and whatever CI/CD process use mostly because GitHub Actions, this is gonna be a shocker to all of you, integrates really nicely with GitHub, right?

[00:01:45]
And so the very first thing we're gonna do is we're gonna have it run our unit tests. And that is great, and that is something that almost every other CI tool on the planet can do. I mean, any CI tool can do any of this stuff, but the other nice part about GitHub Actions is you can script lots of things in your application, right?

[00:02:07]
So for instance, anything that GitHub has an API for, you can script. And it's super easy cuz a lot of the infrastructures there, they have an API, you could have always done it. But you can do something where it's like, okay, if you do work on an open source codebase and is a first-time contributor, you would have something like automatically greet some, silly but doable, right?

[00:02:32]
More practically, some things we use it for is we have a public repo, which is our open source project, we have a private repo, which is just the SaaS implementation of that. And our SaaS app is a superset of our open source app, which basically we use Svelte's package thing.

[00:02:54]
And we bundle the open source as a package that then the cloud app consumes, which the ability to do user management and stuff. The nice part is when we bumped the npm version in a PR, that will automatically trigger something that automatically bumps the npm version of that inner cloud process.

[00:03:16]
So the act of cutting open source release automatically updates it to cloud rather than prior. Cool, you merged into main, all right, neat, now you do npm publish. Okay, cool, now it's on npm, now go into the other one and update the dependency, open up a PR on that.

[00:03:33]
Cool, get a code review, merge it in. And nobody got time for that, right? And so workflows can signal other workflows and all those things, and you can kinda build these automated systems, other things. One of the things I plan on using for in the next sprint or two, which is we merged our server, our web server, repo into our UI repo, right?

[00:03:59]
Because we bundle it in that server, we release it, it's weird open source stuff. But like we merged them together, now that said, I don't write Go by choice. And what's nice is now I can look at the file path that those files touch and automatically slap the right label on it so that somebody who works on the server can see the pull requests that are for them and the frontend ones can see the pull request.

[00:04:29]
There's lots of GitHubby things above and beyond your tests, that's the most obvious things, that's what we're gonna do first. And we'll do stuff like generating coverage reports, and eventually saving playwright videos and all that kind of crazy stuff. But tests is a really great first thing to do, but you can listen to issue creation, pull requests, or anything like that happens in GitHub.

[00:04:48]
We'll look at the list in a second. You can script and automate a whole bunch of that stuff. And this is kinda I was talking about before we have a hour-long release meeting that every time I seek to shave five minutes off of it every month, right? Until we can get it down to a normal 15-minute stand up, where we happen to cut a release, and just finding those things and being able to script a lot of your process.

[00:05:07]
Again, the automation, people are more willing to not do anything or convince somebody cut them some slack than they are to turn off the build process, right? And I mean, we all got mad at the build process but not to the point where it causes team tension, right?

[00:05:24]
At least we're all mad at the build process, right? And so having a lot of these things built in becomes super powerful in that sense. So with that, the very first thing we're gonna do is we're gonna go ahead and we're going to build it. We're gonna create a workflow that basically runs our test suite.

[00:05:45]
Like I said, any repo that you have will work in this case, but if you don't have one, there are tests in that repo that I've been using the whole time. So that's the thing that you could do. Let's go ahead and let's see what that looks like.

[00:06:01]
All right, so right now, this is just a normal repo, it has no idea that a GitHub workflow exists. All that you truly need to make something to support GitHub workflows is you can have a dot GitHub directory that has a workflows folder in it. That's it, that exists, ideally, there should be a file in there, and empty folders in Git don't do anything.

[00:06:26]
But with that, you could theoretically begin to publish your first workflow. And I'm gonna kind of just go into, if I go into the README, and we can kind of jump into one of the sections. Getting started with GitHub Actions, let's look at what a first workflow might look like.

[00:06:48]
This is possibly, I'm not gonna say the simplest workflow cuz I could have one just echo or something and that would technically work. But this is the smallest useful workflow that you might see. And so this would be in that dot GitHub directory in a workflows' folder that we'll make in a second, don't worry about that.

[00:07:10]
Let's just kinda talk about the component pieces in here, and then we will go ahead and we will put it in our repo and watch it do its thing. So the name, that's pretty straightforward. It's what name do you want to see? And so I might even do Run Unit Tests or something like that.

[00:07:35]
But anyway, the more important part that comes next is what triggers this workflow? Like I said before, you could do it on basically anything, an issue being created a pull request open. There is a long list that I have linked to here as well. You actually are in the repo, these are markdowns renders HTML.

[00:07:55]
Don't worry, and you can just click on it, and we'll take a look at in a second. There is a long list of things, and for those things, there are even nuances to where you can only when an issue is close, or only the PR is a draft.

[00:08:09]
There's all sorts of little things you can do here. But for our very simple first workflow, we've got on, which is what event are we listening for, and we are going to listen to one of two different events. A push to a particular branch, and you can guess which branch it is by squinting and looking at it, or a pull request targeting a particular branch, right?

[00:08:33]
You will notice that the branch in question here is main, right? Is to say that, hey, whenever someone pushes to main, right, which is usually if you've turned on any kind of branch protections means that they've merged the PR into main. Let's run everything one more time, run the tests, why not?

[00:08:50]
Also, whenever somebody opens a pull request against main, the nuance here is that event also triggers when they push to that pull request, right? So all PRs and any commits to those PRs as well as pushes into main itself will trigger this workflow. For testing notes, you can do pattern matching here, so it could be like, if you had a feature branch, right, which is feature dash, it could be anything to a feature branch, right?

[00:09:18]
In fact, I say this particularly cuz I recently got bit by this one, which is in December, we decided not to release anything because we didn't wanna work for the second half of the month. So we made a code freeze branch, I think I called it Long December after the Counting Crows' song, I don't even like the Counting Crows.

[00:09:46]
I don't know if that's why I don't like the Counting Crows upset or even Counting Crows' reference upset. I don't dislike them, I just don't like them, this is absence of a failure as a passing test, right? And so this was set to main, which meant that all of the PRs we opened against the code freeze branch didn't have our CI/CD process run against it, right?

[00:10:07]
Which was a lot of fun when it was time to then merge that branch into main, right? So you could theoretically comma separate, you can do pattern matching, which is feature dash, like a wildcard. I say this cuz I didn't do that, and I suffered the consequences, right?

[00:10:23]
I will leave as an exercise to the viewer slash reader how much of the content of this workshop is things that have bitten me in the last 18 months, right? And so here we got any of those against main, and then we have jobs. Jobs are things that should be done.

[00:10:41]
And this is just the arbitrary name of it, right? build-and-test, right now, it just tests. But you can clearly see I took a bigger one and whittled it down to the smaller version. And then for those jobs, jobs have a few things. There are other things a job can have, but most importantly, what kind of OS is it running on?

[00:11:05]
And then what are the steps in that workflow? On GitHub Actions, depending on how fast you would like things to be, you can run on, just give me an Ubuntu server you have laying around, I'll take it. However, let's say hypothetically we're building electron app, right? Well, you got to build electron app on whatever OS you wanna run that electron on.

[00:11:28]
So you can signify macOS, you can signify Windows. That said, as most of you all know, Mac minis are more expensive than a Linux box, right? And that translates down to how many Linux, generally speaking, choosing Ubuntu is going to have the best network throughput, it's what the Internet is built on, right?

[00:11:57]
You wanna get fancy, and if you need to compile some Windows things or you need to use Xcode, then you got to use that OS, right? But if you don't really care, if you're just trying to take some text JavaScript and make it some smaller text JavaScript, anything will work, so we'll use a ubuntu-latest.

[00:12:15]
There are some other options here, you could have jobs that rely on the completion of another job, but we'll get to that later. Then the most important part are the steps. And really, this actually really well suits all the basic things you can do, which is you can either run what we'll call an action.

[00:12:34]
You can, I say, use an action because the words mean things. You can use an action, which is basically just a different YAML file with different commands in it, or you can run a command. The one nuance here is that, yes, you look like these, look like Bash commands.

[00:12:54]
Fun fact, they are. The one nice part is your workflow actions are either YAML like this, so even when we break stuff down to its own action later on this course, we'll go do it in YAML. The nice part is the other way that you can write an action other than just shell scripts and run is JavaScript.

[00:13:14]
So the nice part about being a JavaScript engineer in 2020, whatever year it is, and so those are kind of the pieces. So we stepped through the steps, and we can kinda see each piece. So this is a prebuilt action that we say uses, right? And so this is already built, and we're just kind of referencing it, which is anything with action slash is usually built by GitHub, right, cuz that is org/repo is really what that is.

[00:13:43]
The same way you might have GitHub.org, or your username slash your repo name. Org/repo, they own actions, check out. Would anyone like to venture a wild guess what action/checkout does?
>> Checks out the Git repo.
>> Checks out the Git repo, right, which is also known as cloning down, which basically means puts that code base on to this Ubuntu machine that we're running.

[00:14:11]
So generally speaking, pretty common. Now, do you need that one if you're doing like, it's an issue and if they didn't put what environment I wanna auto-comment, be like can you add more detail or something like that, right? Then you don't need to check out the repo for that, you can just use the metadata, who the author was, or what the content of the issue was, so on and so forth.

[00:14:34]
[COUGH] All right, here's a hard post lunch question for y'all. Set up node. Don't all, not everyone at the same time
>> Does it install node?
>> It does, it does, it does. Of course, it does the actions, and you could literally go to github.com/actions/checkout and you can see that code.

[00:14:56]
As of this moment, I think this is still true, and hopefully, if you're watching this later, may or may not be true. Third party actions or anything you're using from the marketplace has to be a public repo. You can write your own actions and put them in a folder, but in terms of sharing and stuff like that, so all of these are, literally, when I say you can just look up the code, you literally can.

[00:15:23]
And then the other thing that we can do in a GitHub Actions is run shell scripts, or like I said before, JavaScripts. So we'll start at the bottom, npm test, we know that one, we've seen that one before. And so we have that one in place, and the new one was npm ci.

[00:15:42]
Does anyone know what npm ci does? I know that I'm supposed to use it, I don't really know what it does.
>> I cheated and read ahead in your notes.
>> Yeah, yeah, yeah. So read my notes back to me.
>> It's a variation on npm install with a few different caveats.

[00:15:58]
>> Yeah.
>> It insists on having a package lock JSON.
>> Yeah, yeah, yeah.
>> It'll error out instead of updating package lock JSON, if something doesn't match, that seems incredibly useful.
>> Yeah.
>> It deletes node modules of present, it doesn't write to package JSON, and it'll uninstall all dependencies.

[00:16:13]
>> Yeah, so it'll basically do that thing what we all do, even if it doesn't work, when our slings aren't working, we blow away node modules and reinstall everything, it'll do that. And it won't update it based on letting the little patch version slip and stuff along those lines.

[00:16:27]
So it is basically a version of the npm install, but for CI/CD processes, and then npm test. And we know that if your tests fail, we may not know cuz we didn't talk about it. But we have probably grokked that you get an error code that is not successful, right?

[00:16:45]
And so very much like our tests, if we exit with a zero, everything is good, if you exit with any other number, everything is bad, right? And so the absence of blowing up is a sign that everything is great and that that step passes, right? And honestly, we'll expand on this, we'll add stuff to it over our time together.

[00:17:09]
But this is basically, if you just wanted to run your unit tests, you basically make a dot GitHub folder, I'm saying this on purpose, with a workflows directory. And you just name something dot YAML with this code in it, and you now have your unit test running on every PR to main.

[00:17:27]
Let's do it.