The include keyword in GitHub Actions empowers you to add custom variables to your matrix strategy, providing flexibility beyond standard configurations. In this video, we'll explore how include allows you to define specific combinations of variables, enhancing control over your workflow runs. You'll see how this feature enables you to tailor jobs for unique environments or scenarios not covered by the default matrix options. By leveraging include, you can efficiently manage complex build processes with greater precision. This technique helps you streamline your CI/CD pipeline, making it more adaptable to your project's evolving needs.
Transcript
[00:00] A job called family and we're going to create a strategy with a matrix of John, Mindy, and Ben. Which means that this family job will run three times because this matrix has three values in it. Then we can reference this matrix value people inside of this step and to test it we'll use the act CLI. So I'll just type act here and this will run all of the jobs, specifically we'll get hello Mindy, Ben, and John. Because this family job was run three times.
[00:30] If we want to include additional data inside of here, we can swap this over to use the include syntax and then I'll hit tab to accept this. And I'm going to swap out these people and grab them all and I'll call this first. And we can also add last and I'll just accept all of these suggestions. So now I can say hello matrix first and matrix last. So if I run this again I'll type act, hit enter, and you'll see we get hello Ben Jones, Mindy Miller, John Smith.
[01:02] This was especially useful for me in a scenario where I had to find a runner and the runner was Ubuntu latest and I also had a runner which was Mac OS latest. So in runs on I passed in the runner and in some of my steps I needed to know the platform and architecture I wanted to run per task. So I could easily attach platform Linux, platform Mac, architecture x64, arm64, whatever, and then the matrix could use the platform and the architecture because they were bound to this runner variable and each time this job is run, let's just rename this to build, each time this job is run even though it uses a different runner each time, we can attach some other variables in there so that from the matrix we can pull in platform architecture, run this again, and you can see we now have hello Linux x64 and hello Mac arm64.