Build Step & Branch Protection Rules

[00:00:00]
>> Now, GitHub actions are super powerful. You can do all sorts of crazy stuff like we talked about, but the very first one is super easy. Now, to our point that we can write so many less tests now that we have TypeScript. It would be nice to have TypeScript validate that things were okay too.

[00:00:19]
The easiest way to do that for most setups these days is to just run the build process. Well, there must be why he called it build and test. And so like we can basically try to add another step to this script, right? That also tries to build the application, that will expose any kind of like TypeScript issues as well and will allow us to see that as well.

[00:00:46]
And so we wanna just add another run command to not only do NPM test but then also do like NPM run build, and get that process going as well. So why don't you add that in and then we'll take a look and we'll see it all together? Cuz I'll do it too and kick it off and then we'll view it and play around with it a little bit as well.

[00:01:10]
So the workflow that we had before called build-and-test but it only tested. So our mission was to also make it build. And there's a challenge mode here, which is like a segue into the next thing we'll talk about. But let's just deal with the major piece, which is also built.

[00:01:31]
Now, if you're using my repo and it's live there was like one issue with the type alias that stopped it from building, which is great cuz now I can show you kinda the good and bad. So this is our first one where we had that NPM test script that exited with a one.

[00:01:48]
Then we fixed it and then like build the build did legit fail. So you can kinda see a few things, right? Which is one, it fails, and you can click in. This is in the Actions tab you can also get to it from the PR, where you can see okay, here's where it blew up you can see all the test stuff as well but that all pass, so nothing to look at there.

[00:02:11]
But with the NPM run build, you can see that it did blow up and the kinda cool thing that it will do as well is, where did it go? Here it is, the annotations. And you might have to do some configuration but what's really cool with this is if there are lint warnings now also see that here as well.

[00:02:36]
It will annotate the PR with like, yeah, this didn't break the build but you got a little silly thing here, right? In this case, it's just showing you, because you think a lot of these stack traces have the file name and have the line numbers and stuff like that.

[00:02:55]
So it is able to kind of show you and it included the error code of two. And so I fixed those and then I added them to the commit. So we go back to actions and you can see that it passes at this point, right? You get a sense of what branch it was on, so on and so forth, you can filter, in this case, we're only doing on pull request.

[00:03:16]
You can hear all the different statuses. And I will show you some of the events you can watch for and a little bit as well. The branch, the actor, there is one it is me, cool. So here you can see that in this case it went successfully, which means now I know that hey, this built before merging into main and all the tests pass, right?

[00:03:39]
Great, now nobody has to run it manually, or anything along those lines we now know with confidence that theoretically, you can't merge bad code in the main. The word theoretically is doing all the work in the sense because I totally can, right? In fact, there are no rules in this repo, I can do whatever I want.

[00:03:59]
And as an admin, you can always kinda do whatever you want. But this is why most companies have principal place access, which is at most decent sized companies not even anyone on your team has admin access to your own repo, right? And it's to stop you from doing things like this.

[00:04:16]
Because in a lot of cases there are rules around things you need to do to be compliant to its name is SOC2, is that the one, right? Something, something Enron. So now that there are a lot of safeguards in place to make sure you can't do bad things.

[00:04:30]
So how do we set that up for ourselves? We can kinda go into the Settings and you can also get here. We'll see if in the pull requests to go to Settings, I go to Branches, and I have not protected any of my branches. Most importantly, the main one, the important one.

[00:04:46]
So that's settings and branches. But also I'm pretty sure if you go into the PR, it will also say hey, you can have some rules here, would you like to add a rule? It's very much like you should have some rules. Which brings you to the same page, was the one clicking on main.

[00:05:07]
For most things with GitHub, actually I was going to say GitHub, actually. This is true for most things with GitHub. If it is open source, almost everything is free. If you would like to make stuff private, there's some number of minutes that you get for free, I work at a SaaS company, I don't understand how pricing works, even for the thing I work on.

[00:05:29]
But I also work on open source projects, I don't care. So here, we can do all this stuff, but if you did make this repo private and you don't see the ability to do all this stuff like that's why, that's mostly why I mentioned it. So this is the main branch and again you can do pattern matching here as well.

[00:05:49]
Require pull requests before merging means that you can't push to main. This one is tricky when it's a repo with just you, but you're also an admin and you can bypass that rule anytime you want. So you can do that or do not do it, which is acquires approvals.

[00:06:07]
Cool, all sorts of little rules, generally speaking, I'm not gonna check most of these boxes because I don't want to. Because I'm one person demoing in front of people, but you should probably check. Almost all of these boxes, this one's tricky because I tried this one one time, and I wanna have it like auto-assign the most helpful person, right?

[00:06:34]
But that person has to do it. And you know what you never want is the person who had like code over everything being me. And you never want the manager to have to do a report request review because he's in meetings. [LAUGH] Right, and he's not the best on that, right?

[00:06:51]
And so I had to turn that off. And also we have people work in London, yeah, it's time zones, life is hard. But that one, maybe not. And I'll talk about what you can do to code under stuff in a second.
>> For the require approvals one, is that anybody can approve it?

[00:07:05]
Is there a way to set it up so?
>> Anyone, I believe what this one has to be with write access to the repo, right? You can change the number to, I think that they have to have-
>> So anyone who can push?
>> Yeah.
>> Okay.
>> Yeah, I don't think I could be wrong on that one because-

[00:07:25]
>> I think it's like collaborator.
>> Yeah, collaborator.
>> It's a permission level, yeah.
>> It's not just a Rando, not a Rando.
>> So is there a way to change that?
>> Not, I don't think you can change the level.
>> That's just GitHub setting.
>> Yeah.

[00:07:39]
>> Yeah.
>> Okay.
>> Maybe with enterprise.
>> You could use code owners. So all kinda basically the high level. Yeah, it is path name, username and it means that like if you are touching this file, this is really great for a mono repo, we have different teams contributing the same repo.

[00:07:54]
Which just like somebody from this team has to be the one approves it on their part of the codebase, right? And so you can get a little bit more granular with who can do it not just anyone in the org or anyone as collaborator. You can say only the people who are in this file, can do it.

[00:08:09]
Yeah, which again, I'm on the full team is eight people. It was the eight of us, right? So I tried to get very specific, always this file, I worked on this, so I would like it to auto-assign me, but then it couldn't. And you can require a view from the code owners.

[00:08:28]
There's nuances here, but generally speaking, don't let people push to main without somebody else rubber stamping it, require approvals. This is the one we care about, though. Require status checks to pass before merging because what is the point of running the test suite if you're gonna let people merge anyway if it fails?

[00:08:48]
Because then you've just merged failing tests into main and nobody likes the person who does that. This one makes sure that like you've like rebased in main with that as well. And so you've got like the latest version of main that you're based off of it's not like an old version, and so on and so forth.

[00:09:07]
Cool, and you can pick which checks, and hypothetically yep, I have one which is built-and-test, which is run by GitHub actions. And that will say cool, before you can merge into main, this check has to pass, right? Now, admins, not as clever as admins can always override this and lisences a personal repo.

[00:09:29]
I'm setting up a lot of rules that don't apply to me as the only person who can collaborate with this repo. There's some other ones in here, and these are, again, these fall when we talked about that systems, process and then patterns. This comes down to a lot more of the process piece, whether or not you choose to use code owners or something like that, it's like a process.

[00:09:50]
This one, if you've seen like comments can get resolved in the threads, this is say all comments need to have hit the resolve button. So you can't be like, you should change this and then somebody else comes in and approves it, and then you just ignore that other person, right?

[00:10:06]
Sign commits are if you do it from the UI, they're signed. But otherwise, you need to get a cert. Yeah, lots of like ways that you can tweek this. Every box you check add safety, except for the lock branch, which just makes it, I guess lock branch makes it really safe, right?

[00:10:26]
Because it means it can't change. Yeah, this, yeah, this one, actually will stop you from being able to break your own rules, but then you could also turn it off as an admin. So [LAUGH] yes, you can lock the door that you have the key too. Yeah, obviously, every box you check has a certain level of safety and a certain amount of hassle, right?

[00:10:48]
So this is a process piece of how do you manage a team, managing a code base, both either as a member of the team or the leader of the team. It's like figuring out what level you're comfortable with. Now, to be clear, it is very tempting to be all New Year's Eve about this or New Year's Day.

[00:11:11]
Which is it's a new era of quality in our code base and check every single box and put on draconian and it's a great way to have a small-scale revolution on your team. It is like the natural inclination, it's like, I found out about these features, we're gonna have the best process ever, I'm gonna make everything safe, and then there will be riots in your team.

[00:11:35]
So my suggestion that you didn't ask for is the obvious ones of make sure the checks pass. I think everyone could be on the same page with this, don't merge failing tests or a broken build. That one seems non-controversial to me, right? Somebody should review this PR before I just open and merge it myself seems non-controversial to me.

[00:11:59]
If we want later I can pull up my own repo and see which ones I like, some of them have been checked and unchecked by people on my team. [LAUGH] Right, and so we can see what the current state of the world is if somebody's interested in a little bit.

[00:12:11]
Cool, and then you can see I can turn off the ability of what I just did earlier, which is force push. Again, sometimes you need these things. But I would start small and build it up and you can create this. Cool, so now I've got these branch protection rules in place, and now I can't merge a broken build in, review is required.

[00:12:33]
Did I check the box? Not allowing me to do that, which is going to become problematic for me in a little bit because ain't nobody else in this repo. That's the thing that I will have to address at some point, but at least I demoed that it worked.