GitHub Actions: Cloudy with a Chance of CI/CD - by Serafim Karparov

This talk focuses on automating workflows using GitHub Actions, exploring how to create and customize cloud-native automation pipelines. The speaker, Saraphim, a software architect at IBM, explains the tight integration of GitHub Actions with the GitHub ecosystem, presenting its advantages such as cost-effective solutions, scalability, and security features. He compares GitHub Actions with Jenkins, highlighting easier setup and maintenance as key benefits. The session outlines how to define workflows using YAML, create custom actions, and manage access through the GitHub secret store and deployment protection rules. Additionally, he covers efficiency tips, including using caching actions and self-hosted runners for improved performance.

Challenge accepted. [music] Challenge Challenge accepted. Challenge [music] accepted. Challenge accepted. P2 is always [music] challenge accepted. And now time to talk about something we all rely on every day, automation. >> Specifically, how to take those pipelines in the cloud and make them run smoother than freshly brewed coffee. >> Our next speaker is a software architect at IBM leading teams in in building CI/CD frameworks, container pipelines, and

cloudnative workflows. Zafim Karparov is passionate about Java, GitHub actions, Docker, Kubernetes. And when he's not debugging pipelines, he's been the best friend of his four yearear-old son with cold beer in hand. Saraphim that is not his four-year-old son. >> Today, Seu is going to show us how to automate smarter with one of the most popular workflows engines what out there, GitHub actions. Please welcome me with big

rounds of applause. [screaming and groaning] Challenge accepted. Challenge accepted. I think I'm audible now. Okay. So, hi everyone again. My name is Saraphim. I work as you uh heard for the big bull IBM. And uh in our department at um IBM, we use uh GitHub actions a lot. So today we'll understand what these GitHub actions actually are and how to use them them smarter and we'll leave

some space for you to dive a bit deeper inside the uh more let's say advanced stuff and I want to start with uh some apologies about uh the title. So initially it was uh a reference to a famous movie but unfortunately I kind of uh influenced the weather outside but for the people of our guest coming from Netherlands it they feel almost like home. So again sorry

for the Bulgarian community here. So uh what are actually the GitHub actions given the time of the day? uh some people might think that these are the actions that you perform in GitHub during your lunchtime or you perform other things. Other like uh people probably in San Francisco may think that these are the actions that they do during uh their UART driving. So it's a recent example

uh of a brave guy that uh was doing his work during uh probably uh workday and he was brave enough to to let let's say um not face his manager in his own uh yuber uh yuber drive. So let's see what they are actually about. These are um let's say cloudnative solutions for automation and um they are integrated heavily within the GitHub ecosystem. You can customize the

workflows with pre-built actions or you can extend uh uh these actions or these workflows with your own uh implementation. They are YAML based. Yeah, YAML is emerging even more in nowadays. And the use cases are from building notifications, deployment, basically everything that you can think of that could be automated. So for an instance, the last section that I wrote recently was one for extracting some readmies from

Jira, uploading them to our proprietary service and making them available in one of our um AI assistants. So yeah, sky is the limit here as you can uh notice. What are the key benefits? Well, their tight integration with uh the repositories and the whole uh GitHub ecosystem is probably the most important one. You have all the events that would happen in a repository. You have the secure

store. You have basically the issues uh what uh could be rised inside uh GitHub and uh you can tightly couple your uh workflows or GitHub actions and respectively GitHub workflows uh with them. There is a broad range of pre-built actions that are either developed by GitHub uh themselves or by a community or even GitHub uh partners. And uh the next thing easy paralization and scalability options we

will see how to achieve that. It's a almost like a piece of cake to scale your uh pipeline, scale your work workflow and uh also consider what uh is the cost about it. So, GitHub provides really cost- effective uh tires. One of them is free. So, you can start using GitHub actions today directly. And uh yeah, that obviously applies to smaller teams. If you are a big

enterprise, you may go to some enterprise plans and uh and use them for your daily activities. So, how many people actually here use Jenkins today at their job? Okay. and uh half of the room let's say and how many people use GitHub. Okay. Okay. So we have quite a diversity here. Okay. So I've decided to do a comparison with Jenkins because it seems to be uh the

tool the CI tool that is used the most. Uh actually my first job when I started my career more than 15 years ago was to write Jenkins plugins. It was all Java extension points. You have to build the things. It was actually not called Jenkins at that time. It was Hudson before Jenkins was forked but it was uh yeah let's say a challenging task for a student

training and uh yeah Jenkins is still there today and uh yeah decided to just make a few obvious things that uh uh we can compare with the GitHub actions and the GitHub workflows uh capabilities. So what's the setup for Jenkins? Yeah, it requires somebody to set it up. It could be easy but you have to maintain it with GitHub actions and GitHub workflows. You just have them

out of the box. If you have a GitHub repository and your administrator has if you're an enterprise has um approved the usage of actions, you can create your first workflow today. Doesn't need to set up a separate server and maintain it. Uh there is a use yet for Jenkins we can say that complex pipelines could be defined with uh uh the enhancements that uh we had in

the recent years before that everything was about freestyle jobs clicking here and there while with u uh GitHub actions it's just YAML and it feels more natural for a devop person to to implement it well there is a pay a pay as you go which is obviously the choice for enterprises but uh for small teams and for your personal usage yeah you can use it for free

uh for Jenkins you have the ability to run it for free but as we mentioned it uh requires the infrastructure as long as the community um GitHub has a thing called GitHub marketplace for actions you can browse uh any actions that are already developed as we mentioned either by GitHub by GitHub partners or even by somebody here in the room. So it's extremely easy to implement an

action and we will see actually today how how this could be done. we implement our our first action while uh in Jenkins there's a large pug ecosystem again kind of similar thing extensibility Jenkins it's mostly Java and uh yeah as I mentioned in in the beginning of my career I have to deal with that while now with GitHub actions you have several options actually I could say

sky's is the limit again so you can use the so-called composite actions which are actually shell actions And you can write things in in bash or reuse another actions and put them as uh children of your own and uh let's say let's say compose them like a Lego you can use javascript using the note type uh actions or you can use docker which actually makes it possible

to use any other language. So if you are a Python developer or uh I don't know C# developer, you can compose your logic inside a container image or even I believe just a docker file, GitHub will make the build and produce that image that uh performs the business logic and you can uh use in general any programming language as far as you use uh docker. So uh

yeah that was uh kind of the theory and the uh basic stuff. We will show some code and uh how um a GitHub uh workflow actually looks like. As we can see uh the first thing is the workflow name. Yeah, we have to name them. Uh in our case, it's called uh weather workflow and uh we see that it will do some things about uh weather. There

is a a section which begins with on where you specify when this workflow will be triggered. Similar to other CI tools, there are possibilities in general to trigger this um uh workflow using some events or uh manually like using the dispatch. In dispatch uh workflow dispatch, you can also specify inputs which uh the user who triggers the actual run can specify. You can have defaults. Yeah, all

the natural things that you would expect from a CI server. uh as long as the events basically you have many options. Most of the use are uh triggering the workflow during uh pull request to compile the code, test the code, do some linting, so on and so forth. And once uh you have a push for example uh in the main branch logically the next thing is to

define what this uh workflow will actually do. that happens via the so-called uh jobs. These are independent pieces that you can chain. They could be completely independent or you can say this job needs the other and they can be chained and uh be made sequential. You can also combine everything. So a job has a name and ID which is completely userdefined. Uh in our case it's called

build. And uh the next thing that one has to do is to define where this job will be run. In our case, this is uh Ubuntu latest. It's a label. So it's not a single VM or a container or something else. It combines a set of uh uh let's say runners, a set of workers where uh yeah your uh activities will be run. Uh actually the cool

thing with Ubuntu latest I believe it's available out of the box in public repositories is that it's already there for you. So if you have a GitHub repository define such a workflow and define this uh Ubuntu latest label the actual runner will be created for you. You don't have to register your own VM. You can use it. Uh yeah, GitHub makes it available for you and it

actually has a lot of uh tools preset up like cubectl, helm CLI and uh yeah many many others. So in general if you are an enterprise or you can you want to register something specific you can bring your own VM or a cloud runner or even your own machine. It's a piece of cake again. So GitHub gives you the instructions you supply a label and then uh

yeah your V VM could become um a runner. Uh we will see by the way uh uh a note for how these things could be scaled with runners in one of the next slides. Uh the jobs are actually composed of steps and the steps here we have the uh not a limitation but the standard that they are always sequential. So uh you can run jobs in parallel

but the steps should be always sequential. In our case we see that we have just two steps but they should be illustrative enough to uh demonstrate uh let's say two flavors. The first one is an action called checkout. Yeah, it's obvious what it does. It uh check out uh our code for in this case from the same repository where the workflow workflow resides. But you can supply

some of the inputs, check out another repository, different branch, whether to check out subm modules or not. So many options that are available in the actions documentation. The key here is that this action actually comes from the GitHub marketplace. So it's created for you available out of the box by GitHub and you can use it uh freely. Um the next one is the so-called custom action. So

in or custom step actually in this case it's uh just running a shell command. In our case winter is coming. Yeah. Uh it's not exactly winter. If you go but if you go in the mo you'll see that there are already Christmas decorations. So yeah that uh it's almost here if you ask somebody from uh demo shops and uh it's completely written uh by you by you.

You can define any shell command here. But now let's say that this uh custom uh step is something that's really useful for somebody probably somebody in our organization probably really somebody in the whole GitHub community and we have to make it reusable. How to make it? Well, we will write our own composite action. So, uh yes, it's really straightforward this to be to be done. And as

you can see, we are defining a single YAML file which is always uh designed by contract. It's called action YAML and it resides in some repository. In our case, it's called organization names weather action. So, yeah, that's important. the repository name and organization will be the way how people from your organization or the GitHub community will will actually use it. So it has its uh own metadata

which are usually the name the description that the users can browse and of course the inputs. So you can parameterize your composite actions and uh define uh various number of inputs. In our case, it's just the season and it has a default value which is winter and it's required by default. So if uh we didn't have the default value and somebody uses the action without specifying the

season then uh yeah GitHub will be smart enough to tell that it u it will fail and you will have to supply it. Then it's uh actually the set of steps that our composite detection contains. In our case, it's a [snorts] set of um again shell shells steps if we can say it that way. But I as I mentioned in the beginning, it could be also completely

different GitHub actions that either you wrote or somebody else wrote or yeah, GitHub provides out of the box. So yeah, in our case it's just u the the shell the shell ex uh where on line 10 we see that there is a using key keyword here in the DSL and it's composite. It actually defines uh the the type of the um custom action that you use. Remember

in the beginning we said that one can use uh uh docker or node. So yeah this is basically how you how you define uh the type how to use it. Well, uh let's go back to our previous example. We still keep the checkout action which was uh and is available out of the box in GitHub. But now instead of uh instead of defining uh run instruction run

DSL that will run our custom logic. In this case, we just uh define the usage of uh our completely new GitHub action that we just wrote. How to do that? Well, we define a name. And remember we said that the repository name and organization is quite important. So in the uses keyword we designed define exactly that and of course uh use the uh required version uh required

version sorry the required version that uh uh the action has. So actions evolve. So they use semantic versioning. And in general, basically these are taxs or branches that the owner of the repository has created before that. How to parameterize? Well, obviously using the width keyword and defining our uh uh custom input. In this case, instead of the default winter, we specify uh the spring. And at the

end of the execution, we'll see uh spring is spring is coming instead of uh winter is coming. And of course the new thing that we added in addition which is brace yourself the additional step in our uh security best practices. After all actions are again code and uh we uh or they are libraries or something that is reused from somebody if they are not written uh by

us. And we should be really cautious about security here too. And uh there are several things that everybody should have in mind and uh do whenever uh third party action is uh being involved inside uh uh your workflows. Always review and scan the source code of these actions especially as I mentioned if they are third party. Check for the verified actions batch. So it means that the

creator is a partner at GF GitHub and it obviously kind of means like uh that it's a verified action and you can uh be like like more open for using it. Pin action versions. What does it mean? In our example, we show that uh we are using um uh the V10 0 version the semantic versioning and we are not using for example directly the main branch. We

don't want to always consume the latest available thing out of the box. We may want to review it. There might be some uh breaking changes and also there might be the case that somebody intentionally injected something new inside uh this uh branch or tuck. So my uh own preference and uh the team's preference where I'm working for uh for is to use directly hashtags instead of uh

tax the hash of the commit that corresponds to the particular uh version that we're using. So this way you are uh better on the security uh on the security side and uh yeah obvious thing avoid sharing sensitive data with untrust detections. you don't want to put your uh username and password or cube uh uh config file directly to an action that is considered untrusted and people can

can steal your secure data. If we get a bit aside of the actual actions that are used there and look at as a whole on the GitHub workflow there is an out ofthe-box uh secret store called GitHub secret store. You can find it on the settings uh page and you can it's actually looks pretty simple but you can uh basically handle most of the use cases that

you need for your uh workflows. It you can define uh key value pair where the key is your uh actual name of the secret and then define uh userdefined secret. It could be just a username API token or could be the the whole cube config uh file that you use for connection to uh to cubernetes. Securing environments is a good practice when you have a large team

and there is a respons there is a responsibility just for several of the team members to uh deploy to production for example. You don't want everyone to be able to approve rolling out your changes. If you have the whole pipeline deployment from source to the final production deployment, you don't have don't want sometimes to uh give the possibility that to happen completely out of the box. There

is a way to define environments inside GitHub and protect these environments using uh deployment protection rules. What does it mean? You can list I believe up to six people that can have to manually go and click approve on the last step that will make the final deployment. They'll receive an email and only they will be authorized to do um to do certain things. Of course, you can

define also um secrets that are bound exactly to this environment. So if you use uh an action or a part of your workflow um touches such a secret, it should be uh pointed out that this uh that piece of code has to deal with this this environment and somebody have to manually click the approve button of the of the execution. By default, GitHub injects a thing called

GitHub token which uh usually has um access to basically doing almost everything inside your repository. You can control that too. So in your workflow you can define what are the privileges of the GitHub token and reduce them. For example, just reading the data. You can use also other tokens for other repositories but be uh be strict and uh in general use the least privilege for these type

of tokens. Well, we saw the uh security perspective. Let's now try to scale the things. Uh so what we have here we have the same workflow that we saw uh before that but uh yeah in this case we have something new which is called strategy. So in this strategy we say that the strategy here is is matrix. What does it mean? Well, it means that GitHub will

do a matrix execution of all these additional parameters or the DSL options that are defined under the matrix keyword. So in our case, we have the four seasons, spring, summer, autumn, winter and we also have different runners. For example, we want to execute uh this action on various environments. And uh yeah, you can uh already probably uh think that and see that this workflow will be executed

more than once. Actually, it will be executed yeah eight times to multiply it by four. And we almost didn't do any any change. We just reused the matrix uh parameters in the run option. In our case, oops, let's yeah, in in the run option just accessing the matrix contracts with the OS keyword and the similar thing is also uh in place for the season input for in

our custom action. So after executing this, yeah, this is the bounding that I was talking about. After executing this, we will see that an execution of the build state build job will not be uh just one. As I mentioned, we'll see uh eight different executions uh doing the combinations of all the uh parameters that we saw. So yeah, easy way to to scale your action and actually

your workflow and uh test various uh on test on various environments or with different parameters. Uh let's explore some efficiency tips. Um, GitHub provides out of the box an action which is called cache action/cache. It uh can speed up what of uh installations that you are doing. For an instance, if you're using grado, we know there is a gradal cache, grado wrapper and sometimes you want to

uh uh yeah or always you want to speed the things up and uh reuse what was downloaded from a previous execution. Well, the GitHub actions cache is exactly what uh you use in this case. Yeah, it could be reused with mpm walk files. Uh again, you have it out of the box with with the action. There is a nice way to scale also your uh runners or

the workers that are available inside uh your uh GitHub workflow. How to do that? Again, a project that I believe is backed by uh GitHub itself called actions runners controller. uh it's a Kubernetes operator. If you have a Kubernetes or better open shift, yeah, you can uh use this actions runners controller and uh easily scale your own self-hosted runners. So self-hosted runners is basically runners that you

you own and dynamically create u runners which are essentially ephome. So there is some job to be done. They are um they are created the job is done and they are destroyed. So this is uh basically saving you a lot of infrastructure and you can uh imagine that uh this is completely based on containers. You can also switch your uh own base image that is used inside

this uh actions runners controller and have all the necessary tools that uh that will be that you need during your workflow. So yeah, that was uh a brief introduction to GitHub actions. Uh feel free to explore it. It's very nice. As I mentioned in the beginning, you can do it right now. And uh yeah, it basically does not require any pay as you go account. You have

it directly available in your GitHub repository. And uh yeah, today it's cloudy with it was cloudy with a chance of CCD, but we also have a chance of winning a world cup. So, as the organizers mentioned, we will have the ability to watch uh the game during the launch time and I think that was from me. I'm open for questions. [applause] >> Thank you very much, Seo.

Any questions? >> There's there are all there are lots of questions like four of them. The the game starts at uh 1:30, so you you can stay here asking questions. [laughter] Hello. >> Yes. Hello. >> Uh, you already touched on this a little bit, but >> essentially the actions are open- source repos maintained by people. >> Exactly. >> And you said we should always look for the

verified badge, right? >> So, my team handles payments, so it's quite sensitive. If somebody leaks our stuff because they were malicious, can we then sue GitHub because they had the verified batch and essentially guarantee this was a vetted repo? because I'm not going to sit and read the the source code myself probably. >> I I Yeah, it's a legal question, but I can I I think it's

Yeah, it's possible. So, what I um advise actually, especially if you have a GitHub enterprise server, your own uh hosted GitHub uh enterprise instance is to clone the actions, scan them, and reuse them from your own uh instance, not directly from GitHub. This way you will guarantee the safety of uh whatever you >> Thank you. >> You share the next question. >> Yes, I have a question

over here as well. Hi, my name is K. >> Um my question was around the runners. So I know you can have local runners. Can you also have cloud hosted runners where you have run and some HTTP endpoint? So if I understood the question uh you you are asking whether you can specify an HTTP endpoint that represents a runner. Is that the case? >> Yes. So I

don't want it on GitHub. I want it on Asure on the >> Absolutely. So it's not an HTTP endpoint. You have to just register it. If you have a an VM or a container in Asia somewhere, you have to run I don't know it was around two shell commands that contain a token against this runner and it will be able to self-register against the repository. You will

see it as a labeled runner there and yeah you can use any cloud provider or any machine or whatever you want it it doesn't have to be owned by by GitHub. Just GitHub provides some out of the >> Yeah. >> Thank you. with a t-shirt. >> And there was one more question just like there. >> Okay. >> Hello. Um have you tried or do you know how

hard is to add um AI agent or something like this in in those steps? >> Yeah. So uh yeah I noticed that I don't have a single slide with AI on my presentation. AI agent I haven't tried to add an agent but it should not be a problem. I can tell you that AI helped me in another direction to write my recent uh GitHub action and uh

giving uh having this uh let's say openness for the GitHub community makes AI really uh knowledgeable about how to use all that ecosystem and it's a piece of cake for uh an agent or a assistant to to write your uh workflow or to uh use the outputs of your workflow and do and to react uh based on on these outputs. But personally I haven't tried like an

agent agentic uh implementation or usage of of the workflows. >> Thank you very much. The next question you will have to ask them in the speakers corner where you can uh meet Sarah. Let's now send him off the stage with Vick. Round of applause. SARAH. Thank you. Yeah.