Python Continuous Integration and Deployment Using GitHub Actions: Create a Workflow & Add a Step

Key Takeaways

Hi, I'm Phillip. Welcome to getting started with GitHub actions where I try to help you getting started with GitHub actions. As a Python developer, you may have heard of CICD. CICD stands for continuous integration and continuous development. And these systems help you to produce high-quality software and streamline development. In other words, when you're using CI/CD systems, you're building workflows that perform actions like testing your app every time you push the code to a remote repository, making sure that everything works as it should. And having such a CI/CD pipeline can really help you that you don't deploy a web application, for example, when there are errors. That's very important when multiple developers work on an application, but even when you're working alone, having a CI/CD pipeline can help you to be sure everything works as you want it to work. There are multiple providers for CI/CD services, but if you get started, GitHub actions is a great starting point. GitHub actions is free and conveniently integrated into GitHub. So, if you have a GitHub account, then you're just a few steps away to using GitHub action workflows in your own projects. What exactly are these steps? Well, that's what you will learn in this course. You will start by setting up a Git project and then build and publish your first workflow. You will leverage existing GitHub actions that other people created. And then you will continue by using Python in your workflows. And finally, create an automatic testing pipeline with Piest. To get the most of this course, you should have a GitHub account and some basic Git knowledge. The GitHub account is important because otherwise you can't use GitHub actions. And as for the basic Git knowledge, if you know how to commit your code and push it to a remote repository, you're good. And to get started, you don't have to have a repo ready. You will do this in the first lesson of this course after this overview. Okay, let's get started. In the next lesson, you will set up your project by creating a Git repository and checking that pushing and pulling your code works. To work with GitHub actions, you need a Git repository, more specifically a remote repository and a local repository. And in this lesson, you will set everything up and check if it works. You will create your remote repository first, then clone the remote repository, change the readme markdown file locally, and then commit and push the changes to see if everything works. To get started, you need your browser and the terminal. On the left side, you can see my browser where I'm already at github.com/new, which is a shortcut to create a new repository. And on the right side, you see my terminal. In the terminal, I will clone the remote repository in a moment. But in order to clone it, let's create it first. If you want to follow along closely with this course, I recommend to use the same settings as I do because this will make following along way more convenient for you. The name of the repository is Hello GitHub actions. If you want, you can add a description. I'll skip this. I set the repository to private so I can play around with nobody seeing. I want to add a readme file so that there is something in the repository already. And as the git ignore template, it's a good idea to use the Python git ignore file, no license, and create the repository. Once the repository is created, click on the green code button and copy the remote repository URL. Now in the terminal, create your project folder. I'm using hello-ash gh for GitHub and then dash actions navigate into the folder and then clone the repository. Make sure to add a dot after your git clone command because that way you ensure that the git repository is cloned into the current folder. Or if you don't care about the special folder name, you can skip the folder creation and just clone the repository without a dot and then the repository name will be the folder name. Next, let's make a round trip to check if you can also push to the remote repository. To do so, make a change to the readme file. Since we are in the terminal already, let's use the terminal and type echo and then in quotes back slashn because you want to add a new line first. This repo is my playground for GitHub actions and then to greater signs readme.md. The echo command takes the text inside the quotes and prepares it to be displayed or used. But instead of displaying it to the terminal, you use the append operator. That's the two greater signs to add the text to the end of the readme file. Don't forget the back slashn at the beginning of your string to add the description on a new line in the readme file. Now, if you have a look at the state of the repo, you see that the readme file was successfully modified. That means you can stage it, create a commit, and then push it to the remote git repo. Head over to the browser and reload your remote repository. There you can see that the changes are in the readmi file. That means pushing to your remote GitHub repo works as it should. And that means you can get started with creating your first GitHub action in the next lesson. In this lesson, you'll create your first GitHub workflow. You'll start small and then over the next few lessons you'll enhance it with more functionality. Before you create your first workflow, have a look at the GitHub actions page of your repository. If you haven't added any workflows, you will see some suggested workflows for your repository for deployments and continuous integration and so on. Feel free to pause this video and investigate some of them by clicking configure. But please don't add any of the configurations to your project yet. We want to create the workflows from scratch in this course. And by this course, I mean now hop over to your editor. I'm using VS Code, but of course you can use any other editor of your choice. One convenient thing about VS Code though is that it's tightly coupled with GitHub. You're welcome. GitHub workflows are based on YAML files with a predefined structure. You can choose any descriptive name you want for the file. However, it must live in a specific folder inside your project, specifically ingub/workflows. In the spirit of greeting the world, I name my file hello_world.yaml. And now before adding any content, let's commit this empty file and see how GitHub reacts. Save the file, stage it, and add a commit message and then push it to GitHub. Now visit your remote repository in the browser and click the actions tab again. Instead of seeing the overview of proposed GitHub workflows, now you see a failed workflow run. I know failure never feels great and these little red icons can be scary, but what you're seeing here is actually good news. Although the run failed, GitHub recognized your workflow file and tried to run it. If you click on the name of the workflow which is the commit message, you can see the actual error and it says no event triggers defined in on. In other words, GitHub wanted to run the workflow but can't do it without some events that you need to define in some on section of your file. Fair enough. If GitHub wants to be triggered, let's trigger it. In GitHub actions, a trigger is an event that causes a GitHub workflow to run. There are many kinds of triggers, for example, when a pull request is created, when you push a commit, or when someone opens a new issue. But GitHub offers way more options like tag commits, requests by another workflow, or even manual triggers that don't run automatically. If you're curious, you can check out the GitHub actions documentations and look for the events that trigger workflows document. On the screen on the right side, you can see all the events that you can use to trigger workflows. To get started, you'll implement a push trigger for your workflow. Hop over to your editor again and open the hello world YAML file. In the first line, write on colon push. This means whenever you push something on any branch, the workflow should run. Now, you could commit this change, push it, and see what GitHub makes out of it. But I save you this step and just let you know that GitHub will complain and say that it needs a job to run because each workflow must have a single job section. So, in the next line, write jobs colon and inside the job section, you can define one or more jobs. Well, let me be clear here. You must define at least one job and you must give it a name right away. Here, it's a good idea to be descriptive. For example, say underscore hello. The say hello line needs to end with a colon because you're opening a new section. And don't forget to indent the content because similarly to Python, indentation is hugely important in YAML. As a rule of thumb, every time a line ends with a colon, you must indent the next line. When you're creating a job, the first thing to do is to define the runner you want to use to run your job. A runner is a GitHub hosted virtual machine that executes the job for you. GitHub will provision and deprovision the virtual machine. So you don't have to worry about maintaining any infrastructure for your GitHub actions. You can use Windows, Mac OS, or Linux as virtual machines. But generally, it's a good idea to use Linux unless you have good reasons to use Windows or Mac OS. To define your runner, add a runs on property with the virtual machine. So runs- on colon and as the virtual machine, use Ubuntu-L latest. So that way you're telling GitHub to use the latest Ubuntu version. You could be more specific with the Ubuntu version, but since you're not doing anything Ubuntu specific, it's usually okay to just use Ubuntu latest. Then in the next line, this time in the same indentation level as runs on at steps colon. Steps are the main part of a job. So while jobs are the main part of a workflows file, steps are kind of like the main part of a job. They are the actions that need to be performed when executing the workflow. So for example, this after steps indent the line again add a dash space run colon and then echo hello world. With the dash at the beginning you tell YAML that the value of the steps property is a list. Later you'll work with multiple steps but for now this one step is okay. And I would say we're good for now. Ready to commit and push the changes and we've got a green dot. That means your workflow ran successfully. Let's have a look at what exactly GitHub did. When you click on the commit message of a workflow, you can see the detail page of it. You can see that the workflow belongs to the hello world yl file and that you ran a job named say hello that was triggered on push. If you click the say hello box then you can see the logs of the workflow. You can see how GitHub set up the job and what operating system was used exactly. In the run echo hello world section you can see your echo command and the hello world output below. And finally, you can see that the job was completed successfully. And if an error occurs while your workflow runs, you can always go into these logs to investigate what went wrong. In the next lesson, you will polish your workflow a little bit more.