Kevin Feasel guides viewers through GitHub Actions, an essential tool for automating workflows and integrating continuous integration/continuous deployment (CI/CD) practices within GitHub. The video covers the basics of GitHub Actions, including setting up and managing runners, understanding YAML workflow files, and triggering workflows using events. Through a practical demonstration, Feasel illustrates how to create, modify, and execute workflows, showcasing the platform's flexibility and potential to seamlessly manage devops tasks without leaving the GitHub environment. For those transitioning from Azure DevOps, the similarities with ADO pipelines will be particularly enlightening.
Highlights
GitHub Actions are the heart of automating workflows on GitHub 🫀.
Use self-hosted runners for tasks behind a VPN 🔒.
YAML files define workflows that can run jobs in parallel or sequentially 📜.
Explore pre-built actions in the GitHub Marketplace to simplify tasks ⛳.
Trigger workflows manually or with specific events for flexibility 💪.
Key Takeaways
GitHub Actions automate workflows and integrate CI/CD effortlessly 🚀.
Runners can be GitHub-hosted or self-hosted for more control 🏃♂️.
Workflows operate on YAML, making them both powerful and flexible 🛠️.
Various triggers can initiate workflows, like pushes or issue creation 🚨.
Kevin shows step-by-step how to create and manage GitHub Actions 🔄.
Overview
Kevin Feasel introduces viewers to GitHub Actions, a tool that transforms how developers handle automation within the GitHub ecosystem. He starts by explaining what GitHub Actions are and why they are crucial for devops practices, particularly in continuous integration and continuous deployment (CI/CD). With GitHub Actions, you can automate numerous tasks, triggering them based on specific events, like code pushes or pull requests.
Next, Kevin dives into the mechanics of setting up GitHub Actions. He explains the concept of runners—virtual machines where actions run. Developers can choose between GitHub-provided runners or set up their own self-hosted runners for more control, especially for tasks that require a secure or custom environment. This flexibility is key to tailoring the CI/CD process to different project needs.
The video wraps up with a hands-on demonstration. Kevin walks through creating a simple workflow, reveals how it can run jobs in sequences or in parallel, and how to leverage GitHub’s marketplace for pre-built actions. He underscores the power and adaptability of GitHub Actions, which allow users to manage devops processes right within GitHub, thus eradicating the need for external CI/CD tools.
Chapters
00:00 - 01:00: Introduction and Overview The chapter introduces the presenter, Kevin Feasel, and his consulting firm, Cataly Services LLC, which specializes in the data platform space with a focus on SQL Server. It mentions the series' previous topics, including forking repositories and working with issues and projects, setting the stage for the current discussion on GitHub and DevOps.
01:00 - 03:00: Understanding GitHub Actions and Runners The chapter introduces GitHub Actions and their functionality. It references a previous discussion on Azure ML and GitHub Actions, linking to a video for further details. The speaker intends to cover the basics of GitHub Actions despite some overlap with the topic of ML Ops, emphasizing that GitHub Actions are essential tools for automating tasks in GitHub, similar to concepts found in Azure DevOps.
03:00 - 05:00: Self-hosted Runners and Use Cases The chapter discusses how different CI/CD tools, although varied in workflows and scripts, fundamentally serve the same purpose of executing code upon specific triggers. It focuses on GitHub Actions, particularly the concept of Runners, which are virtual machines used for executing tasks.
05:00 - 07:00: GitHub Actions YAML Specification GitHub Actions provides virtual machines called GitHub Runners, including options with Windows, MacOS, and Ubuntu Linux, for use in code deployment. Additionally, users can set up self-hosted Runners on virtual machines they have created in cloud services like Azure or AWS, or within their own on-premises environments.
07:00 - 08:00: Workflow Triggers and Practical Examples The chapter discusses the use of self-hosted runners for executing GitHub actions, highlighting scenarios where it might be advantageous. One key reason is the need for operations to occur behind a VPN or within a corporate environment. Using public GitHub Runners, which are based on Azure VMs, could expose corporate data and services, whereas self-hosted runners can perform jobs within the secure confines of a corporate network.
08:00 - 17:00: Demo: Building a GitHub Actions Workflow A chapter titled 'Demo: Building a GitHub Actions Workflow' discusses the use of self-hosted Runners in GitHub Actions due to limitations in GitHub's offerings. It highlights that GitHub does not provide runners for certain Linux distributions like Red Hat Enterprise Linux or SUSE Enterprise Linux, offering only Ubuntu. Similarly, it points out the need for Windows desktop operating systems for testing, as GitHub currently supports only Windows Server 2019, not Windows 10 or Windows 11.
17:00 - 20:00: Modifying the Workflow and Adding New Jobs The chapter explains how to modify and add new jobs in a GitHub Actions workflow. It briefly introduces self-hosted runners and provides a link for further details. The chapter describes how GitHub actions use a YAML specification to set up workflows, which include a name and parameters indicating when the workflow should be triggered.
20:00 - 24:30: Using Marketplace Actions and Sequential Job Execution This chapter introduces the concepts of using marketplace actions and executing jobs in sequence within a workflow. A workflow can be triggered by certain actions like a push to a repository and consists of one or more jobs. Jobs in a workflow can either run in parallel or be set to run sequentially using the needs attribute to specify dependencies between jobs. Each job comprises multiple steps, each representing an action like running scripts, checking out repositories, connecting to services like Azure, or saving files to cloud storage.
24:30 - 30:00: Adding Workflow Triggers for Issues In the chapter titled 'Adding Workflow Triggers for Issues', the discussion focuses on running custom shell scripts as part of GitHub action workflows. It mentions the availability of various actions in the GitHub Marketplace and open-source repositories. The chapter explains with an image example on how to reference one of these actions, specifically using 'actions/checkout@v2'. This points to a GitHub repository in the actions organization named 'checkout', highlighting the specification of version two. By linking these steps together, users can construct their desired workflows.
30:00 - 33:00: Conclusion and Next Steps The chapter discusses the importance of automating development workflows, exemplified by actions such as checking out code from a repository, building it, conducting unit and integration tests, deploying the code, and ensuring the service runs correctly. This process is part of a classical development workflow. The chapter also mentions the use of GitHub Actions for infrastructure as code (IaC), which will be explored further in subsequent parts of the series. Additionally, it introduces the concept of workflow triggers, highlighting the numerous events that can initiate these automated processes.
Get into Action with GitHub Actions Transcription
00:00 - 00:30 it's time for us to take action GitHub [Music] actions welcome to this video on GitHub and devops my name is Kevin feasel and I am the proprietor of cataly Services LLC a consulting firm which specializes in work all across the data platform space especially SQL Server we've talked about forking repositories and working with issues and projects so far in this series in today's video I'll give you an
00:30 - 01:00 introduction to GitHub actions and we'll see how they work I've talked about GitHub actions a couple of times on this channel including a classroom discussion around Azure ML and GitHub actions I'll link to that video in the show notes below but if you'll indulge me I'd like to tread over some common ground here as not everybody will be interested in the specifics of ml Ops actions are the way that we can get things done in GitHub in Azure Dev Ops we have a notion of
01:00 - 01:30 pipelines other cicd tools have their own ideas about scripts and workflows and whatnot at the end of the day all of these tools are doing the same thing executing some specific code upon some specific trigger these are all fancy code running tools now let's dig in specifically to how GitHub actions work the first thing we need to think about with GitHub actions is Runners Runners are virtual machines that you can use to
01:30 - 02:00 run code GitHub provides its own Runners called surprisingly enough GitHub Runners which are Azure VMS we can use for code deployment they have VMS with Windows Mac OS and Ubuntu Linux installed and we can choose from among any of those three we can also use something called selfhosted Runners self-hosted Runners are virtual machines that you have built out either in a cloud service like Azure or AWS or in your on premacy environment you can
02:00 - 02:30 execute GitHub actions on one of these Runners as well and there are a couple of reasons why you might want to use self-hosted Runners first some of your operations may need to happen behind a VPN or within a corporate environment GitHub Runners are public Azure VMS and you may not wish to expose your corporate data and services to those VMS instead you can have a self-hosted runner that lives within the corporate environment execute the job
02:30 - 03:00 a second reason we might use self-hosted Runners is because sometimes we need something GitHub doesn't provide for example perhaps we need to deploy things using Red Hat Enterprise Linux or soua Enterprise Linux there are no GitHub Runners for those distributions of Linux just Ubuntu similarly we might need to try things out in Windows desktop operating system like say Windows 10 or Windows 11 the only versions of Windows GitHub Runners support are windows server 2019 and
03:00 - 03:30 2022 regardless of the reason if you do go the self-hosted runner route there are a few steps you'll need to follow to get it working I'll leave a link in the show notes to show how you can do that next let's talk about the actions themselves GitHub actions follow a yaml specification and look a bit like this example each yaml file defines something called a workflow the workflow has a name as well as indicat on when we would
03:30 - 04:00 trigger this workflow such as a push to a repository a workflow also has one or more jobs these jobs can run either in parallel or sequentially if you use the needs attribute in a job and specify the name of another job within each job we have one or more steps each step is some action that we can take such as running a command line script checking out a repository connecting to Azure or saving a file to Azure block
04:00 - 04:30 storage sometimes you'll need to run your own custom shell scripts as part of GitHub action workflows but there are a variety of actions already available to you in the GitHub Marketplace and in open source repos this image shows you how to reference one of these using actions checkout atv2 this points to a GitHub repository in the actions organization called checkout and we are specifying version two of it in the image by linking these steps together we can build out whatever
04:30 - 05:00 solution we need one example would be to have workflow actions to check out our code from a repo build it run unit and integration tests deploy the code and ensure that the service is running as we expect that's a pretty classic development workflow we can also use GitHub actions for infrastructure as code which is something we'll explore in a later video in this series now let's talk about workflow triggers there are are dozens and dozens of events which
05:00 - 05:30 can trigger a GitHub actions workflow to run and I'll give you a link to all triggers in the show notes that said I listed a few of these in a prior video and I'll recapitulate them here as well the workflow dispatch event is for when we want to run a workflow manually we can schedule a workflow if we'd like to run it at some time during the day or some time interval schedules accept KRON syntax so if you're already familiar with that you're in good shape if not
05:30 - 06:00 there are plenty of good websites for building cron schedules when we push into a specific Branch or into any branch we can execute a workflow and the fourth one I've seen pretty frequently is executing a flow on poll request this might do something like build the code with changes from the poll request and then run a set of unit and integration tests against that built code to make sure that the code change doesn't break anything but these aren't the only
06:00 - 06:30 events we can use so I've included a link to the list of events and you can get an idea of how flexible this GitHub actions system is this is our academic overview of GitHub actions now let's go to the demo and see what it takes to build one out we are going to take care of exercise 2 task three in this training on implementing devops practices the goal in this task is to create a GitHub actions workflow and get it to do a few things we're first going
06:30 - 07:00 to create a workflow and Trigger it manually we'll add a pair of jobs to the workflow including pulling an action from the GitHub actions Marketplace we'll have these jobs run in parallel at first and then make them sequential jobs then we'll add a trigger to fire off this job whenever anybody creates an issue in the repository finally we'll create that issue and see the Carnage that it entails that's quite a few steps but this will go by pretty quickly so let's get started in order to perform
07:00 - 07:30 this work I'm going to show you the easy way first using the GitHub actions interface to see it let's navigate to the actions menu option I don't have any GitHub actions workflows set up yet so GitHub will make some suggestions for US based on the code we have in the repo we can see Docker containers and net desktop actions in the suggestions then in deployment we see deployment to a variety of cloud services there are also plenty of options for security
07:30 - 08:00 continuous integration Automation and more you're welcome to check out these templates and some of them are really useful but for our task we're going to stick with building the workflow so I'm going to select the link to set up a workflow myself that creates a blank yaml file in my main branch nature AB of vacuum so let's start filling this in the first thing I'm going to do is rename the file to First hyen workflow
08:00 - 08:30 yml the next thing I'll do is give this workflow a name I also need to give it a trigger to run manually in GitHub parlance that's a workflow dispatch next up we're going to add a simple job to the workflow I'll call the job job one and it will run on Ubuntu Linux that job will contain two steps one that I'll call step one and one that I'll call step two each of those jobs will run a simple command to Echo a bit
08:30 - 09:00 of information to the log the first will write out log from step one and the second will write out log from step two and that'll do it this is a perfectly reasonable and utterly useless job I've had some of those before anyhow the next thing that we'll do is trigger this job let's first select commit changes this will bring up a modal dialogue giving me a few options including the ability to to create a new
09:00 - 09:30 Branch for this workflow as a spoiler that's the better approach but we aren't there yet so I'll commit directly to the main branch with that in place I can navigate to the actions tab in GitHub on the left hand side we see my first workflow entry I'll select it and it will bring up a fairly sparse page but on this page we can see a note that this workflow has a workflow dispatch event trigger that means I can run the workflow manually to do so I'll select
09:30 - 10:00 the Run workflow dropdown and choose run workflow that will kick off the workflow while it's getting started let me explain what kicking off a workflow actually entails GitHub will spin up some compute for me on an Azure virtual machine they own once that happens I'll see a record of it here in the GitHub actions menu I can select the title of this to drill into a job graph this provides a visual display of each job in
10:00 - 10:30 our workflow we only have one job so let me click on that from there I can see log details on the left hand side I see my job so I could switch between jobs quite easily on the right hand side we see several check marks and step titles the first step is to set up the job and that happens automatically if I drill into it I can see some details about the GitHub Runner and the prep work that
10:30 - 11:00 it's doing for me let's drill into operating system I did specify Ubuntu hyen latest in my workflow file so we get the latest version GitHub supports which is currently Ubuntu 2204 LTS selecting Runner image expands that section showing me the version of the image the software they pre-install and More in case you're interested in seeing these versions you can select the markdown link and see in GitHub a listing of what they install by default
11:00 - 11:30 there's a lot in here including AWS Azure clis tools for a variety of programming languages Integrations with several database platforms and a lot of what you would need as a developer on a wide variety of platforms that said it doesn't cover everything so you may need to install your own software on it as well next I'll drill into step one the first step that we created we can see one command hand to run an echo
11:30 - 12:00 statement and I can drill into it as well as see the actual Echo statement and the result in the log step two covers the same thing unsurprisingly the final step is to complete the job I'll drill in on it and we see an entry about cleaning up orphan processes this like the setup step is something GitHub adds automatically and we don't need to worry about it what I'd like to do now is modify that workflow and add a second job I'll go back to the code tab on here
12:00 - 12:30 all GitHub actions workflows are in a GitHub folder and a workflows subfolder let's navigate into that folder and we'll see first workflow. yaml I'll select that yaml file this gives me a display of the file and code let me talk briefly about this page as I didn't cover it in the overview video when we look at a code file GitHub gives us a pretty good amount of information by default we see the code itself we can
12:30 - 13:00 see that GitHub adds line numbers to the code making it easier to identify a line of code during a discussion or a review if I switch tabs to blame I can see who is responsible for each line of code's most recent change and when that change occurred there's not much here yet as I was the person who created the entire file all at once but this can be quite valuable when a larger team deals with substantial code files over a longer period of time let's switch out of the the blame View and back to the code view
13:00 - 13:30 we can see in the header that this file is 13 lines long and 11 of them have code totaling 214 bytes of text if I click on a given word like say runs on it will show me any times that symbol shows up in the repo note that this doesn't work on every word if I select Ubuntu latest I can see references if I select name I can see references but if I select step step or echo or something
13:30 - 14:00 like that no references for me okay let's close that box and keep up the learning along the top right there are a few buttons the first one reads raw and if I select that I get the raw text file this is really useful if you need to copy and paste a script into a command prompt I don't however so I'll navigate back into my browser to the full page the next button lets me copy the raw file and the third G gives me a chance to download the raw file I will
14:00 - 14:30 tantalizingly ignore the next Button as that is our destination and like any RPG we need to do all the side quests first if I select one of these lines of code GitHub highlights that line of code and gives me an ellipsis let's select that Ellipsis button it brings up a menu letting me do a few things I can copy the line of code or a Perma link to the line I can view blame for the line which is functionally equivalent to selecting the blame button above I can create a
14:30 - 15:00 new GitHub issue and reference this line of code that makes it easy for developers to know what I'm seeing the next thing I can do is view it in github.io code running within GitHub you can work with files in the repository create poll requests view issues and do a whole lot more in here
15:00 - 15:30 github.com next to the pencil icon this lets me edit the file I can edit it in place which is very similar to the UI we saw before when I created the file I can also open the file with or I could open it in GitHub desktop on
15:30 - 16:00 my local machine I'll choose edit in place this brings me back to the edit screen on here I want to add a second job to the workflow I'll call it job two now I'd really like to use a Marketplace action here rather than echoing something myself there are a few ways to search in the GitHub actions Marketplace but this interface provides me a nice way of seeing what's available to me I'll search for cow say which is a classic toy app in Linux we can see one
16:00 - 16:30 entry available so I'll select it when I select the link it shows me how to incorporate Cales into an existing yaml file let's copy that and paste it below the steps section for job 2 I'll need to do a little bit of formatting to get things right as yaml is a whites space sensitive language make sure that the hyphen before name is one level deeper than steps everything else needs to be lined up with the word name so one level
16:30 - 17:00 deeper than the hyphen we can see that it has a uses command and that ties to the Cal say action by the way one neat thing about GitHub actions is that these action names are actually repositories if I copy this and open a new browser tab I can put github.com in the browser and then paste in the action name hit enter and we can see the cow says action repo if you ever need to dig into the code for an action this this is a really easy way to do it okay let's close that
17:00 - 17:30 Tab and get back to the workflow we have a with Clause that includes the parameters we send to the action there are two parameters text and color for text I'll write the phrase quote ready for prod ship it unquote then for the color I'll choose magenta as a quick warning even though we set the color here there's no guarantee that GitHub actions logs will show things in magenta
17:30 - 18:00 it's a sad world but it's the one in which we live anyhow I now have an updated workflow so let's commit this change I'll commit it straight to the main branch and then go back to the actions tab on the actions tab I can select first workflow again on the left hand side just as before I'll trigger a manual workflow against the main branch we have to spin up a new Runner so this will take a few seconds but pretty soon I'll see it on the screen and canra drill in this time around we have two
18:00 - 18:30 jobs job one and job two they are both in the same box meaning that they are running in parallel I'll select job two and we can see the two default tasks of setup job and complete job as well as our cow says step let's open up cow says and we can see that the cow sadly is not magenta nonetheless we must soldier on the next thing we want to do is to make the two jobs job one and job two sequential that is I want job one to
18:30 - 19:00 complete before job two runs doing that is quite easy as it turns out let's go back to the code tab drill into the GitHub and workflows directories select first workflow. yaml and edit this file once again in the editor there is one simple change we are going to make on the line right after the job two definition I'm going to add the following needs job one this says that job two will only run after Job 1
19:00 - 19:30 finishes I'll commit that change and we'll go back to the actions tab on first workflow I'll once again run the workflow against the main branch give it a few seconds to start up and I can drill into the workflow this time around we see two boxes with a line connecting them this is how we can see that there is a dependency between job one and job two the final thing I'd like to do here is add another trigger on this work flow in addition to running whenever I select
19:30 - 20:00 the button to kick it off I'd like to add a trigger that fires whenever anybody creates an issue in this repository to do that we will not surprisingly need to go back to the code tab one more time we'll get into first workflow. yaml and modify it again in here the modification I need to make is in the on Section right after workflow dispatch I'll add another Clause this says that whenever I open an
20:00 - 20:30 issue we will trigger this workflow I'll commit the changes one last time then we'll go to the actions tab I just want to show you that there are no workflows currently running I'll Now navigate to the issues Tab and add a new issue Jimmy the intern is getting a little big for his britches we are going to put him in place by giving him a task he will never be able to complete clean the aan Stables Jimmy is no Heracles he's not even a Hercules I'll submit this issue
20:30 - 21:00 and laugh a little bit to myself but I'm also going to go to the actions tab because it turns out there's a workflow running note that the title of the workflow is the name of my issue we can see that the name of the workflow itself is below that so this gives us a good idea of seeing what's running and why we now have a functional GitHub actions workflow there's a lot more we can do with GitHub actions and we will come back to this several times because it forms a key part of any devops work
21:00 - 21:30 within GitHub if you're coming at this from Azure devops you may find that the concepts within GitHub actions are pretty similar to Ado pipelines but it's not quite the same and each has its own nuances still what it does provide us is a flexible system for executing code without having to leave the confines of GitHub in the next video we'll learn a bit about the GitHub flow and see how they recommend we work with code development then we'll tie things back
21:30 - 22:00 to GitHub actions with a couple more videos on infrastructure as code and cicd stay tuned for these over the next few weeks we'll have links and show notes in the description below and until we see each other in the next video take [Music] care