Generating Coverage Report Artifact

[00:00:00]
>> So we have our unit test, and our build. And one would argue, could I put a dash dash coverage here? I could, it would work, right? It would run my test and would generate a coverage report. I could absolutely do that. That said, when I get a red x.

[00:00:18]
I kind of want to because I have that threshold in there. You have no threshold, yeah, put a dash dash dash dash coverage here, do it, right? Right now I have that auto threshold set which will fail the build if it doesn't hit that. And so if I see the red x I would like the visual indicator of why I got a red x, because I didn't hit the coverage threshold or because my tests don't pass.

[00:00:40]
So in that case I would break it out into two tests. Again, so some of these are less about the technical limitations, more about the ergonomics of using it. So for us, what we're going to do is we simply. And like I said, you owe it to yourself to Google, like, GitHub Action Recipes at some point.

[00:00:58]
Because whatever, like, there's, if not only, like, don't copy and paste the code. A lot of it's bad. But at least for the inspiration of things you can do. Because a lot of it is, pull in this action that either somebody else pre-wrote or is made by GitHub, or looks reasonable or something you might choose to do yourself, right?

[00:01:19]
But again, there's like auto commenting on GitHub issues, right? Which is somebody runs an open source repo I might want at some point in my life, but if you were in a private one, it's not useful. Stuff that is kinda unique enough that it's not worth all the time to do as a group.

[00:01:33]
Like stuff like running your tests. Think we should all do that one, right, cool. Building the assets, yeah. Running a typscript checker. Weird little stuff like, we have one thing kick off an npm version bump to a different repo and then kick off this other thing and deploy this way.

[00:01:51]
We have, like, a Rube Goldberg machine that's actually particularly elegant and beautiful, but not really generally applicable. But you owe it yourself to at least do an inspirational journey to see what's out there. Because there's, like, wild stuff. You can basically control anything in GitHub. And also make cURL requests to, like, make a Slack notification based on this thing happening, so on and so forth.

[00:02:13]
But for us, we're just grabbing this actions/upload-artifact@v3. Where we'll archive a coverage report with the name coverage-report and the path coverage, right? The challenge that I'm giving you is do something very similar with the build assets. It's not spiritually any different, but it's just a way to kind of move your hands and fingers and do something on your end.

[00:02:37]
So as you can see, it ran. I've got three parallel jobs at this point. And I have this new artifact, and it's called coverage-report. And it downloads a directory. And you know what that directory is? A zip file of the coverage folder, right? So you could at least audit.

[00:03:00]
You have that as an artifact every time. And like I said, we did this with the coverage report because it was a thing. It could be your build. It could be optimized image assets, right? It could be, if you're building an Electron app, it could be the built.

[00:03:15]
Like you could use, like we said this before when we're introducing GitHub Actions. You choose to build it on Windows, build it on MacOS, build it on Linux, and then have the built assets that you're doing stuff with. When we release our CLI, it's a Go binary, we compile it, right?

[00:03:32]
You download from GitHub releases, right? We use it internally to move stuff around between workflows as well because you can query it with the GitHub API. You can move stuff around with it as well. There's lots and lots and lot of reasons that are somewhat unique to your life.

[00:03:46]
Luckily, the same action/archive upload artifact rather, @v3 will work regardless of use case, because all it takes is a directory and a name, and then you have this ability as well and you can do that. And again, you could theoretically, if you had that enforcing the threshold. I would again be very light touch with it, only do core files.

[00:04:08]
Don't do everything all the time because I dropped, one of the draft runs of this, forgot that I had left that on and it dropped a slight bit and then I had to like my build failed. Maybe that's not what you want. The other thing you can do with GitHub actions.

[00:04:25]
And we won't because it's just like a one-liner. And the nature of it when I tell you what it is will explain to you why we're not doing it. You could put a schedule in there. Like instead of like, you like it on like pull request to main, you could also say at 1:30 UTC every day, like maybe you run a bigger test suite, right?

[00:04:50]
I'll say it now and then we'll revisit it when we talk about playwright. You can run playerwright against all the browsers. Every PR, that's gonna take some time. You gotta download them, yada, yada, yada. And yeah, I will probably get in trouble on Twitter, I'll say it. You might choose for PRs just run it against Chrome, right?

[00:05:09]
However, we're gonna actually cut a release and deploy to production. Okay, now Safari, and Firefox, and all the rest. Right, and so you could theoretically, maybe you don't break a build on the coverage report on the thresholds. But maybe you like choose to run it every day and have it notify you.

[00:05:27]
Either with a broken build in the actions that doesn't stop a PR from going in but you can see, or have it log to Slack, or whatever. To show you like, hey, you're below the threshold. And that doesn't necessarily mean you're gonna stop shipping code, as if you did it on a pull request.

[00:05:45]
But these are the systems that I'm talking about in the processes. This is more of a true process at this point of, hey, maybe at sprint planning we take a look at the code coverage report that was generated an hour before sprint planning every day or every other week, right?

[00:05:56]
Something along those lines of, what are the systems that keep you accountable? Maybe, you know, if you're on the process of getting towards a given accessibility standardization, you run it every so often. You can manually kick off an action as well. And you might choose to do different things where you don't necessarily do it every PR, maybe you do it yeah, every so often.

[00:06:18]
Maybe you manually do it. Maybe you maybe instead of failing a build. Like even if you use GitHub but you don't have an open source project. Maybe like for the more egregious accessibility or lint issues, it doesn't fail the build, but maybe it opens up like a GitHub issue.

[00:06:35]
Right, that you can then track or do something with. Or you can do cURL commands, you can make API requests, right? You actually have a GitHub SDK in there as well. Maybe it like hits a webhook in Jira right and it creates a Jira task. We should definitely deal with that now I don't have to break the build.

[00:06:51]
There's nuances of like because that run is a bash I mean you can do other shells bash. And so you can send HTTP requests anywhere you want. You can run JavaScript to do very small things, right? Like all the processes, I said this very, very early in this workshop we have a release we call it release party.

[00:07:10]
We cut a release of our UI every week on Monday at the beginning. And like currently it's an hour long meeting, mostly because we're also joking around. But the goal is every repetitive task, somebody's doing the deploy while we do stand up, and then somebody else is noting all the manual steps we had to do.

[00:07:29]
And we're just slowly whittling it away and slowly getting to the point where it's like, that's tedious, we should automate that.