 So, and hi there, hi again. Today I'm gonna tell you about GitHub actions and our experience of using them. But before we start a little disclaimer, English is not my first language. So if something will be unclear, feel free to just stop me and ask any question or correct me or something like that. So a little bit about me. My name is Sergey Galavin. I'm a CTO at CSSR and author of Remote Talk podcast. Unfortunately it's in Russia, but if you know Russia, you can listen to it. And I'm a huge fan of open source and a hierarchy can see some of my contacts at GitHub and Twitter and Telegram. So if you will have some questions after that meet up or after that talk, feel free to just ask me some question Twitter or in Telegram whenever you want. And a little bit about our company. CSSR is a group of companies established in 2012 and now headquartered in Singapore. We have more than 150 professionals working together to achieve the best results. So, and here you can see some of our clients. Maybe some names here are familiar to you. So, and let's go. We love GitHub and we are huge fans of efficiency. And we believe that everything what can be automated should be automated because machines can do routine work better and more precisely than human beings. Maybe unfortunately for us, maybe fortunately. So, and what the heck is GitHub actions? So before I start to tell you about our experience with the GitHub actions, I'll give you some useful definitions of base terms. So, and the first one is a step. Step is just one particular task like NPM test, NPM run linked NPM install. And all steps can be combined together in a sequence to run them one by one. So, the next one is action. Actions are individual tasks that you can combine to create jobs and to customize your workflow. And the difference between a step and action is that action can be separated and you can share them and can just reuse in different workflows in different jobs. So, and the job is sets or it's a set of steps or actions which can be run in parallel. And it's a, and they run in parallel by default but you can reconfigure it and run in sequentially if you want to. So, and the most important thing you can use in GitHub actions is actually workflow because workflow combine all of these terms together and it's a process which can be triggered by different events, specified events like on create pull requests on push or something like that or changing something in your pull request or in your code. And you can run several jobs in your one workflow. And finally, we have a runner. You can see a word on the screen of that laptop. A runner is a virtual environment which can run workflows, just it. So, and it's a time for short demo. Let me know if something goes wrong. I think you can see the GitHub page now. That's right. Yes, yes. Okay, cool. So you can see here a pretty simple project, completely simple. So here we have only leap.test.js file and it contains only mocked tests which will green forever. So, and in our package JSON we can find only one NPM script called test which only runs just CLI tool to run our tests. So, and let's try to add our action in the empty repository without any actions. So you can do it by pressing the top actions and choosing whatever you want to choose. So, and here you can find many different actions for different animations, for different languages like Ruby Rust or some specific languages and not popular like Dena, for example. And for some common automations like greeting for your pull requests, labeling for your pull requests and so on. So, and right now we need Node.js workflow. So, and you can edit by pressing set up this workflow button. So that's it. Here you can see familiar terms, familiar things like the whole file is a description is a configuration of our workflow, of our whole workflow. And here we can see the name of that workflow. It called like Node.js CI right now. And here we can see some triggers which will trigger our jobs and we can see push and pull request for master branch events. So, and list of jobs. Actually, we have only one job here. So, and it will run on Ubuntu with a different versions of Node.js 10, 12 and 14. So, and the next important thing is our list of steps. And the most important here is NPM CI to install our dependencies. And this one is, we don't need this one because we don't want to build our project. And the last one we really need it's NPM test. So let's edit by pressing start connect and committing that this configuration through GitHub interface. So that's it. So now we have a workflow here and we can see that some check is running now. And we can just open it and can see what is happening now. Okay, let's wait a second. And we can see here that our test bus here. So, that's it. Pretty easy, isn't it? So we just, we just have added one workflow to run our tests and we can specify how it will be, how it will run and so on. So let's continue. Why did we start using them? I mean, by them I mean GitHub actions instead of other tools. Previously our main workflow tools were Travis CI, Jenkins and GitHub. And having different processes and different services forced us to have a lot of user accounts, user settings, project accounts, project settings in all of them were in different places and configs were in different formats. So it was a huge problem or not a huge, but it was uncomfortable for developers to set up a new workflow. So, and we had to ask our developers engineers to set up a specific environment for almost every single project. So, and developers didn't control those settings completely. So, and if they needed to rewrite something or to fix something, they had to ask our developers engineers again to fix it. So, and tighter integration of those services with GitHub was a huge problem. Every new integration required its own unique settings. There was no easy way to reuse automations because when we use, for example, Jenkins, we need to write some automations specifically for Jenkins. And if some other team used, for example, Travis CI, they needed to write their own automation, their own configuration to automate it. So, and teams couldn't reuse those configurations and those automations. So now with GitHub Actions, we can keep all our workflow configs in one place. And following the documentation as code concept became easier because we have all configuration files, settings, special tools for automations in one particular place. And we completely control it right now. Our teams control them and can rewrite and so on without asking somebody to do it. So, and as I said, it's became easier to configure workflows for every single project because every single team now can control all their automations by their own. And even what is more important, our developers can write now their own automation they need and even share them because when you have only one particular format to write your automations and you can store your automations in GitHub and share in the common way for all developers. So it's pretty, it's pretty good right now. So what did we automate with these abilities? So the first automation was running tests obviously and linters because it was pretty easy as you saw previously. And yeah, that's it. Just running tests and linters and maybe this is most important parts of automation every project. So, but we have different automations like pull request validation. It's pretty important because previously our developers had to ask different another developer to just fix some mistakes, some issues in his own pull request. And it was pretty common. Like for example, somebody, somebody just forgot to write some meaningful title for pull request or meaningful message, commit message and so on. So, and we have some rules for our pull request and now we can automate checking of those rules. So, and moreover, we can generate station and task links for every particular pull request. For example, we have some pattern for our station and like that in this example, we can generate by taking the number of the name of branch and in our company, we use tasks ID for naming our branches. So, and we can just generate from template, from template our links, so. Also, we can use auto labeling. For example, it's a, it is pretty useful for projects where many different teams work with that project. So, and you can just auto label by some rules. For example, you can use paths to use some labels for your pull requests like, I don't know, for example, if you have core parts of your library or OTILS or documentation, you can just check what was changed and just set up whatever labels you need. Like for example, documentation label, core label, library label, and it will be obvious to understand what this pull request will change before you will review it. So, okay. And we can automate even package publishing and release knowledge generation by using Git attacks. So, it's a pretty useful if you want to automate deploying of your project or of your package and you can just push the new version by pushing attack and GitHub actions will do everything else. So, let me show you something. Okay, I have another project in which we have all automations got together. Let me show some automations and some configurations of them. Okay, at first was one is change log automation. It will use just npx tool to call GitHub release notes CLI tool to generate our release notes, obviously. So, and it will push it into the releases page which can be found here. And you can see here the previous release with the change log, you can format the, you can change the format of this change log. You can rewrite it by rewriting the configuration file of Grand Hub release notes generator. And in that case, in that particular case, this automation will take comment messages and just use them for generating GitHub notes. So, and if you have some files like archives or static files or binary files, you can just attach them into assets by GitHub action too. So, it will generate a complete page for your releases. Okay, let me show you another one. Danger.js can automate all the data of your pull requests. For example, if you want to validate your pull requests or check some corner cases of format in your pull requests, you can use this tool because it's pretty useful and it allows you to use GitHub API. It's pretty complete and you can achieve different statements of your pull request like, I don't know, current state of changed files, differences between current branch and target one. You can check the description of your pull request. You can check title and comment messages and so on. And you can use even different libraries like a load dash or whatever you want to write automations. So, here we use only one LGS but you can write your automations and here you can see how we automate generating, for example, task link and some checks for some rules. So, and the last one, the last workflow is pretty common workflow for running pretty common steps like NPMCI to install all our dependencies of our project and linked for run linters obviously and the tests for running tests and so on. And that's it. So, let's just create new pull request and check what will happen. I prepared a branch with a simple mistake like missing semicolon here. And if you got previous runs like in my case because I prepared it and I tested it before, you will see that in that case we already have some issues. So, but let's skip it for now and pretend that there is nothing here. Okay, and let's just try to create our own pull requests with the issues with the problems in our pull request title without description, without the signage and so on. Let's create it. So, okay, well, when we create our pull request we will trigger workflows, different workflows and you can see here different runs. For example, you can see here not a CI workflow run and it was triggered by push event and you can see here not CI, another not CI event triggered by pull request. So, the same workflows can be triggered by different events if you specify them like that. And we can see here that not CI workflow will be triggered by push and pull request events. So, okay. So, now we can see the comments from Danger.js and it says that we have some issues with our pull request and that's it. And it generated for us a task link from form template. So, and here in other fails we can just see what happened and here we can find an issue with our code. Yeah, we just missed a semicolon. So, let's try to fix it. So, the first issue is in our code and let's just fix it by adding a semicolon. Okay, that's it. So, and we can write some meaningful comment message like, I don't know, fix the issue for a demo. Okay, and we have two comments for the one task and one of the comments is one of the comments has mean and less description. So, let's fix it by rebasing them into one particular comment message. So, and like that, by squashing them. So, here we have conflict. So, let's fix it too and where is it? Okay, okay, okay. Looks like nothing special. So, let's continue our rebasing. Okay, and let's continue. And remove this message. Okay, and we need to push with the force. Looks like it's done. And okay, while our tests are running let's fix other mistakes. We can just rewrite our title by for example, reusing the comment message here. So, something like that. And just let's use the comment message for our title. Okay, and add an assigning. So, by adding the assigning or fixing the title we rerun our dungeon.js workflow. And after rerunning it, it will update its own comment here in pull request. And our pull request will be in pretty good state for reviewing it. So, let's just wait for a second. Okay, for knowing that everything is, okay, yeah. Looks like now it's pretty good. So, and I mentioned the issue with the labeler. Here we have React Grid Layout library. Maybe it's familiar to you, but few, sometimes go. I added an automation to set up, to specify assign labels for pull requests. And you can see here, you can just add an event triggered by Chrome and it will trigger our workflow every five hours. So, and here you can specify the paths for different labels. For example, here we have documentation label, which will match those paths. And here we have core label and so on. So, but the issue is that when some developers create their own pull requests from forks to this repository, our API, workflows API can't reach their forks and can't check what changes it contains. So, and actually it doesn't work for now. And I will mention it again in my presentation. But yeah, you should pay an attention if you have some needs to automate some working with different repositories like forks and so on. Maybe you will have some issues with that. Okay, let's just continue. So, okay, what if I want to create my own action? Actually, you can use JavaScript library to write your own caption. It gives you an API to access almost everything in the repository from files to, as I said before, to the deeps from one branch to another. And so, automations are limited only by your imagination. So, just use it to create ones. So, and the next way is a Docker container action. It's a more complex way to write your own actions, but it's still more powerful and flexible because you can use whatever you want. And you're not limited by using only JavaScript API or JavaScript library created by GitHub. And what should I know before using GitHub action? It's not free for all. So, you should pay for that, but if your repositories are public or you can use your self-hosted runners, it will be free for you. Or it can be free if, so if it's possible to use it for free, if the free plan will suit you. For example, if your project is not so big and you can just use the limits of 2,000 minutes, it's okay. So, you can just use it without paying for that. So, and as I mentioned before, it's a pretty young service and it still has some problems. For example, I described the problems with a labeler and you can see here an issue which is created a year ago, but it's still open because they have some issues with their security credentials and sometimes you can just can't write some automations which is connected to communication between your repository and forks of your repository. So, and I will take you tips and tricks to spend less. So, okay, just run lightweight tasks first and stop them on fail. So, you should prevent running a whole cycle of your automations like by one npm command, linter type checker or something like that. You should write the most lightweight command first like pull request linter and then code linter and then type checker and then your unit tests and so on or intent tests. And after all this runs, you will run your building and publishing task. So, it will save you a lot of time. And of course, cache your dependencies because if you can cache something, you can just reuse it. So, here an example for caching, not just dependencies, but if your project will produce some kind of binaries or archives, you can store it in some repository manager like HDFactory and download it on each run without building them from scratch. So, it will save you a lot of money and time too. So, and as I mentioned before, you self-hosted runners. Of course, if they are cheaper than running on GitHub. So, but I think if you have some dedicated servers, it will be really cheap for you. So, and of course try to reuse what community has done. So, and just paying attention to awesome actions repository and take a look on it and go through it. And you definitely will find different useful automations and you won't rewrite it at all. So, okay, that's it. Thanks for watching. Here I have some useful links and I think I will send a gist link into the chat. But if you just can scan this QR code right now and achieve the same gist file. So, I'll wait for some time. And that's it. This is my context and context of CSR. So, feel free to ask me some questions right now. Great. Thank you very much, Sergey. Thank you. If anyone has any questions, they can unmute themselves and ask, hopefully. Hello. Hello. Hi, Sergey, Elie here. Thank you for the talk. I just have one question. Would you consider GitHub Actions as a replacement for CI tools, I don't know, like such as Travis, CircleCI, stuff like that? Yeah, yeah, definitely. So, it can suit you if you don't have some really complex automations and the really complex workflow. But I think for Frontend Project, it's completely suitable. Okay. And about CD, like I understand the CI part, but you didn't see this part in fit as well? Yeah, yeah. So, you can just write your own, for example, GitHub Action for deploying Docker images or just binaries or archives or even directories to some place, for example, into your service or something like that. And, but in maybe most cases, you can just reuse with some GitHub Action, so which is written already, like publishing NPM packages, publishing Docker images and so on. Yeah, you definitely can deploy. And if you don't have, you won't find some created section, you will write your own. Awesome, thank you very much. Thank you. It's Sergei, it's Nemanja. So question for you is, I'm not sure of the size of your project and the teams, but do you have kind of estimate on the costs of this? So for example, would you rather run your infrastructure on GitHub Actions? Is it maybe cheaper compared to hosting your Jenkins server or something similar? Yeah, it's a great question. Thank you. So now it's cheaper to run GitHub Actions. And we have different projects, I mean in size, different small ones and huge ones, but now the time of our DevOps engineers are is more expensive than just running it on top of GitHub Actions. Have I answered this question? Yeah, yeah, thank you. Thank you. I have a question following on about deployments. If you're doing a deployment from a GitHub action, does that mean you're putting your sort of authentication into the repository? Yeah, how would you deal with that kind of thing? So yeah, actually not, of course, you can use GitHub Secrets to store your secrets and to reuse it into your workflows. So and here I have an example. Okay, let me show you the automation again. So here I use change lock token from Secrets. So if you have an organization in GitHub, you can store your secrets in the special store for secrets and nobody will achieve it or read it. So, and it's completely secure. Okay, that's great. Thank you. Thank you. I have another question. I know GitLab has been encouraging people to do CI, CD on their platform. Do you know how do GitHub actions compare to what's available on GitLab? I think that GitHub inspired by GitLab automations and by GitLab CI. And I think they maybe not to cope it, but they really have expired of, those GitLab CI. But yeah, I think they will develop it or yeah, maybe in the same way or in the different. And yes, I know that GitLab now, maybe GitLab CI now is more flexible or even more efficient to use right now. But the slide, which I don't know. Yeah, but we love GitHub, we just love GitHub. Okay, good to know. Okay, I got one more question. Okay. You suggested using self-hosted runners, but that would presumably mean we wouldn't be using the same file formats, these action formats we'd be writing. Is that right? We'd be writing, rewriting the sort of tasks in a different language. No, as far as I know, it won't push it to rewrite your automations, your workflows, because it's all about runners. So it's all about just environment in which your workflows will run. So, and that's it. So how would I run this, say I wanted to run this change log file on my own machine? How would I run it? You can just connect your own machine, your own runners to your organization in GitHub and to your GitHub actions. And the GitHub will use your machines to run other sections. I see. Yeah, yeah. So you don't need to write your own infrastructure for running them. Okay, thank you. Thank you for the question. Okay, do you have any more questions? Okay, then I think we'll move on. Thank you, Sergei. Yeah, thank you. Thank you very much.