Adding an option to disable turbo cache in CI

[00:00 - 00:13] In this lesson, we're going to look at adding an option to disable turbo in CI. I'm going to open .github/workflows/ci.yaml, and I'm going to add a step here.

[00:14 - 00:49] I'm going to call the step "Force disable turbo cache", and what we're going to do is if the GitHub event pull request labels contains a label named "🚫 skip turbo cache", then we're going to add "TURBO_FORCE=true" into the environment using the bash shell. If you find that you have more than one job, another place to put this might be in your shared setup action. Right now we just have one action called .github/actions/pnpm that sets up node and pnpm.

[00:50 - 00:59] Instead, you might rename this to "setup-ci" and add stuff like that in there. I'm not going to do that here because it's not relevant to the lesson.

[01:00 - 01:29] Once we have this created, I'm going to go to the command line, check out a branch called "add-option-to-disable-turbo". Commit this as "Add option to disable turbo in CI", push this to GitHub and we need to change our labels.

[01:30 - 01:42] I want to add a new label in here that has the exact name that we put in our workflow. And I'm going to select some orange color because that seems reasonable.

[01:43 - 02:00] Create this label. And if I go back to my pull requests and actually open the "Option to disable turbo CI" pull request. First we should see it run successfully: and it does.

[02:01 - 02:11] It executes using the turbo cache. Then we can go back to the pull request and add the "🚫 skip turbo cache" label.

[02:12 - 02:34] But if we just went with rerun our jobs and execute it again, we're going to see that turbo cache is still used. Why was that? We added the label and we have the change in our action, why did turbo still get used?

[02:35 - 02:45] Did we have a bug? No. This might be confusing, but when you have a single execution of GitHub actions, all the inputs to that action are cached.

[02:46 - 03:07] So if you do a rerun and you change labels between the first run and the second run, the second run is not going to have information about a new label added. Only if you create a new commit are you going to get a new action execution that has the new set of labels for your PR.

[03:08 - 03:47] So to do that, I am just going to force an amend on my commit with "git commit --amend". And then "git push origin --force". We have updated the commit even though we didn't do any change because it's rewritten with amend, it gets a new hash, and now when we go back to the pull request, we're going to see that it is going to correctly read the label and disable caching.

[03:48 - 04:19] The reason why you want to have an option to disable turbo caching in CI is because sometimes your turbo cache might be misconfigured. It might be caching more than it should because you have your inputs done wrong, or you might just want to make sure that you're not hitting a bug that's caused by caching in some way. In any case, it is sometimes necessary, and having the setup for that is worthwhile because as you can see, it is a very easy change to do.

[04:20 - 04:24] And with that, I'm just going to merge the pull request and we're done.