Viewing GitHub Actions

[00:00:00]
>> So once this is in my repository, once I've pushed it, or once I've saved it in the GitHub UI, so it's already live in my GitHub site, then whenever I push code, I'm gonna start to see little icons pop up. And if I go into my Actions page, I can see, hopefully, an action running.

[00:00:23]
And if anybody is not seeing this let us know. So in our configuration, we have these instructions, right? All of these different steps that it's telling GitHub to do. And that is what we can then see actually happening when we look at, let's look at a successful one first.

[00:00:50]
A particular job, it's gonna have either a happy green check or a sad red X. And if I look at the logs here, and it might be yellow if it's still running, I can see exactly what's happening. I can see the logs, and I can go down all kinds of rabbit holes about all of the underlying cloud computing that's happening here, and so on and so forth.

[00:01:17]
So, for example, what it's doing is it's checking out my repository, making sure it has the latest version of the code. It's setting up Node, it's making sure it has Node. It's installing my dependencies with npm Install. So the same as we would do if we were trying to run this project after cloning it from some other cool developer who posted the link on Twitter or whatever, and so on and so forth.

[00:01:46]
And then it is eventually getting to our npm run build command, so again, the same thing that we were doing locally. Then it's doing a whole bunch of stuff about pages that all comes from that built-in pages action that GitHub provides. So anyway, this is all doing a whole bunch of stuff.

[00:02:07]
it's doing some cleanup work at the end that we don't really, again, rabbit holes we can all go down. And then it's like, yep, I did it, I completed the job, and then I get my nice little green check, which just feels so good to see when you have a little green check there on your latest connect.

[00:02:26]
And sometimes you'll notice that, in projects that do the good thing of having a readme, which all projects should have, unlike this one, you will sometimes even see little badges that tell you about different, is the package built, is the build passing, and so on and so forth.

[00:02:44]
So there's all kinds of fanciness you can kind of do on top of this. But this is kind of magic because what's happening right now is basically now every time I push or whatever other thing I configured my job to do, GitHub is auto-magically kicking off all this work for me to spin up a little computer somewhere that's running through all these commands and getting my site live on the interwebs.

[00:03:13]
[SOUND] Lift off. And because I want to show you also, deliberately, what it looks like [LAUGH] when a build does not succeed, for example, or when it when a job does not succeed, rather. When you have a failing job, and you're like, why did that job fail? You can click into the job, in this case, we just have this one deploy job.

[00:03:37]
Complex projects might have many and might be sort of like, first do this and then do that, then do the other thing. But in this case, we can see which steps passed, okay? It got the code, it installed the dependencies, but the build failed. And then I can look at the logs and see what the problem is and perhaps it's the same problem that we saw yesterday about the top-level await is not available in some of your targets.

[00:04:06]
And again, that's because these are the browsers that, by default, Vite is targeting when it does the production build. But in the dev server, it's targeting newer browsers, because it assumes that if you're developing the site actively, you have a more recent version. And so some of these are below the version of Firefox or Chrome or Edge or what have you, that supports top level of weight.

[00:04:38]
So that is, again, like same problem that we saw locally but this is the same problem that this cloud somewhere that's running this code encounters when it tries to run this job. So this is legit actually to show you that when something goes wrong, and I can assure you it will at some point [LAUGH].

[00:05:02]
The interface here, if you're not like, for example, if you're running this locally every time, cool, but once you've got this auto-magicness, you're probably not going to be doing that all the time because you've got like, yeah, I already know, I've got commands to lint things. I've got commands to make sure the build passes and the format is correct and all that stuff, and so this is how we can check out what is going wrong when we need to.