Check out a free preview of the full Enterprise UI Development: Testing & Code Quality course

The "Cache Configuration" Lesson is part of the full, Enterprise UI Development: Testing & Code Quality course featured in this preview video. Here's what you'd learn in this lesson:

Steve demonstrates a shortcut for caching npm packages. Conditionals can also be used in job steps to determine if a cache is available. Running GitHub actions locally is also discussed in this lesson.


Transcript from the "Cache Configuration" Lesson

>> In case you can imagine, I have a general rule, which is, if something seems tedious and common, either there's a faster way to do it or you should make a faster way to do it. You can imagine, caching NPM cache based on a package lock file, is a thing that you might want to do all the time, and that everyone might want to do it.

And that is true, so with that setup node, you can pass it some arguments with the with command, one of them is cache. And you just say what, you're caching, right? Cuz you could be using pnpm, you could be using yarn, it doesn't know. You say, I would like to cache npm, and we can go ahead and we can adjust that and get rid of all of this.

And we can put all of this in here, and that is a lot shorter. And this will work for the specific use case of node. And at least npm, I would love to tell you if I know exactly which are the ones that support some of the syntax was, but you could probably open up the docs and look.

Cool, so we've got that, this is running again now. Most of the reason why I'm demonstrating this is, we can go either to the Actions tab or in here. And instead of node, npm cache is not found, anyone know why? It's just because it happened to use a different key.

It shows a different set of prefixes around that. If we go back to summary, no, we got to go back one. No, I was right. Caches, you can see that I now have two caches. They happen to call it no dash cache, Linux NPM. If you think about it, it is the setup node function, you pass in npm is one of the things that could cash.

It doesn't know that you don't have compiled dependencies so it also saved like what OS you're using. Reasonable things for it to do, the important part that you will notice that that long string of gibberish is the same long string of gibberish. So it works, it just used a different key.

This doesn't cost you anything, so you can delete it if you're very particular, and you cannot if you don't want to. Whatever makes you happiest works for me and those are there. Let's just check the notes to see if there's anything else we wanted to talk about here.

Yeah, this will work for any asset that you want if you are, anything that you are building that is separate. So, there was a question earlier around, what if I have a server repo and a client repo, right? You could theoretically, maybe don't want to recompile the server if nothing changed.

So you can do that as well, let's real quickly, I want to see if I can pull up the docs. Let's go, I'll say, action cache sweet. There, have not a pull it up after a break. You can have it fail in a cache miss, I don't know why you would ever want to do that.

Cross OS archive, restore keys are hierarchies that I can fall back to for the purpose of a locked package json, I don't have a use of that. What I was looking for is, if I can find it fast enough, here it is. If you look at actions cache, you can see that it's using the ID cache primes in this case, which is a made up function, it's not made up, it's real.

Which is, just to get IDs is just a unique identifier, I just explained what the word ID was to you. Unique identifier that you can reference in a later step which is, so we have steps, okay, with the ID cache prime's. Its outputs which are things that came out of that step, cache hit does not equal true, so, you can say, hey did you just build the server and compile it all?

Cache that for me. Go a head and try to pull it from cache next time we run, right, for what ever reason, you need some way to keep track of what version it was or something like that. And that could even just be a thing in a manifest or something like that.

If so, just pull it from the cache and don't recompile it, right? And so you can do some amount of conditional logic with this if. Ours, we don't need that because by definition, it will write to the cache at the end as the post step, if it doesn't find it in there.

But you're always otherwise npm ci no matter what and putting that file there. So this is, only do this thing if it wasn't in the cache and then put it at the end. This is if you need a little bit more granular and fine tune control over that. So that is caching, we will talk about artifacts which is the other thing you can do when we have something to artifact, I could do it with the build assets just for funsies.

But I was thinking maybe I do one and when we have something else, then you could do one too, good like workshop. So we will wait to talk about artifacts then but like anything where it's the actual thing. The built thing that you want that maybe you can release, maybe download or a report or videos from Playwright or your code coverage report or something along those lines that you want to access and use as an artifact.

Caches are mostly things that the actual processes themselves use. Okie dokes, kind of looking through some of these. We did the branch protections, I'll talk a little bit about running the actions locally before we jump into component testing. I'll leave this as an exercise right now, which is just simply adding one more script along with the ones I made that runs prettier.

You can take a look at that, we'll revisit it later when we configure prettier. But I kind of wanna jump a little bit into component testing. We'll go back to the GitHub actions after we do a little bit more testing, when we want to take our code coverage reports, and store them as artifacts.

If you want to run your GitHub actions locally, you can do that. You install this thing called act, A-C-T. That's, I'm gonna guess from the word action. And you do need to have Docker and it will run them locally in your terminal and let you see based on what the heck is going on.

It will let you know if the fans on your computer work and you can squint at a terminal versus a UI. It's there, you can use it, I am not going to have everyone live Docker cuz that seems fraught with peril. But it's a thing that if you really want to run this locally and test it and stuff like that, you are more than welcome to, I'm just bringing it to your attention.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now