GitHub GitHub Checkout, 16 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Running wWorkflows from Pull Requests in Organizational Repos with GitHub Actions - GitHub Checkout

Description

GitHub Actions is an automation platform that enables you to run your CI/CD pipelines in the cloud, or on your own private runners. Actions are fully open source and community powered, and allow you to automate your #DevOps workflows as well as any other custom steps you need during development.

3:41 - demo: manual Action trigger - workflow_dispatch
9:43 - demo: running workflows from pull requests in organizational repos

GitHub Actions Docs
https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions

GitHub Actions Learning Lab
https://lab.github.com/githubtraining/github-actions:-hello-world

Actions workflow_dispatch (manual trigger)
https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/

Actions fork pull request flows
https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

GitHub Actions Marketplace
https://github.com/marketplace?type=actions

Chris Patterson:
GitHub - https://github.com/chrispat
Twitter - https://twitter.com/chrisrpatterson

Sasha Rosenbaum:
GitHub - https://github.com/DivineOps
Twitter - https://twitter.com/DivineOps

A

Hello and welcome to github checkout, I am sasha rosenbaum a product manager at github and my guest today is chris patterson. Chris, would you like to introduce yourself.

B

Sure hi I'm chris patterson, I'm a product manager for github actions.

A

Okay, so our topic today is github actions in general and some new features that we're releasing for github actions. So before we actually get started, I think maybe some of our viewers don't know what actions are. So. Would you like to tell us a little bit more about actions.

B

Sure so github actions is at its core, really a general purpose: automation system for your github, so we've built a workflow language that you can execute based on a series of events, and those events include everything from obviously pushing code to opening issues or opening pull requests.

B

Those workflows can utilize these things called actions which are built by the community, which encapsulate different functionality like uh pushing a building and pushing a docker container, or you know, tagging pull requests based on particular changes and those can run on a set of infrastructure that we provide called hosted runners at github, or actually they can run on your own private runners, one of the key workloads that people like to automate with github actions are their ci and those those pull request, tests and validations.

B

So it's a great system for that, but we do like it because it it allows people to do things beyond that, and I see cases from the community where they automate things like, like, I said, like pull, request, tagging or marking issues as stale or even I saw a really neat use case once where somebody was automatically running regression. Tests on code based on code, snippets and issues that were open, which was kind of neat.

A

Interesting so, basically, to reiterate the high level architecture, we have github hosted runners and you can also use your own, but so you we have a github, hosted runner and you can basically define a workflow which is a yaml file which defines your kind of jobs and steps at high level and then, as part of these steps, you can run steps that are defined in github actions right and these are open source and community driven. So I can write my own action, for whatever I wanted to do. Is that.

B

That's great, that's a great summary.

A

Right and so as part of actions, I can then there's um common actions that are shared with the community right, there's some that we've implemented ourselves that are some that are implemented by our partners, and then I could also go and implement. um You know trigger posting my own pictures on the internet. If I wanted to with github actions.

B

You could do pretty much anything you want to um the community has in the marketplace and the kind of gallery there's a little bit over 4 000 actions that the community has built.

B

um We have a couple of dozen that we've built and obviously they're dozens made by different partners, but when we look across our telemetry, we see on the order of about 14 000, unique actions that are used uh kind of on a monthly basis, and so that says that there's a lot of people out there that are building actions to use in their workflows that are just for them, which we think is also great.

B

You know we want to have that flexibility of you can share broadly with community or if you have something that works just for your project. You know that's fantastic.

A

Yeah this sounds amazing and of course it does sound like it's a really really good um system to be able to run your ci. um So I know there was a couple of features that you wanted to show us today. uh Do you want to go into a demo and show us stuff.

B

Absolutely so the first feature that I want to talk about a bit today is actually something we're released quite a while ago, but I still get questions about it all the time, and that is the sort of simplest possible action which is you know what I've got this workflow that I want to run, and I really just want a button that says, run workflow and so, as you can see back in july here we introduced this thing. We call workflow dispatch and it's just a really basic type of event.

B

That gives you a button and the ability to have some inputs, so I'm going to actually just take and copy the example here and go set up a new walk through setting up a new workflow using this workflow dispatch event and show you how it works.

A

B

All right, so I've got my repo here and I'm going to go and click on the actions tab, and I get a couple of different options here of a bunch of different pre-made workflows that I can choose from. We have a bunch from our various cloud partners, as well as a lot of different things for automating continuous integration, as well as other types of things.

B

In fact, there's one right here for a manual workflow, so I'm actually just going to go set up this workflow and we see that we've got the basic structure of our actions yaml file here, so I've got a name for it.

B

The on section defines what event this workflow is going to run on and you can actually have a workflow trigger off multiple different events. In this case we're going to run off workflow dispatch and I've got one input which is a name. I get a description, the default and then I've got a one job. That's going to simply echo out whatever value it is I put in there. So if I go ahead and commit this to my main branch, then click on the actions tab. I see I have this new entry for my manual workflow.

B

If I click on that, I get this run workflow button, so I'm going to say: hi sasha run this workflow.

A

B

And then we should get.

B

A new run here for our manual workflow, so we can see this trigger. This is running on our github actions, our hosted runners.

B

B

You see the great job running here, it's starting the workflow so take a minute or so to pick up.

B

We system ran pretty quick, hello, sasha uh echoed out right there, it's a super simple feature, but it has just come up on a regular basis. Everybody says: look. I just need that manual button to run a workflow and the ability to have some inputs is just super helpful.

A

So, basically, whenever I want to enable manual triggers for my actions, I just add that dispatch workflow.

B

A

And it allows me to have that manual run action button.

B

Yes, yep, you just add that workflow dispatch event and uh and off you go um like I said, there's a bunch of different kinds of events that you can trigger actions on, and so this is one we showed you, the other really common. One is uh pull request. You know we have lots and lots of open source repos that are making heavy use of the a pull request to allow people to contribute changes and bug fixes to these projects, and they run their actions workflows and make sure that those changes don't introduce any breaking functionality.

B

They run their tests, they run their ci one of the things that we heard pretty quickly as we released actions from customers was. You know that repo to fork and pull request model is, is great and the open source community loves it, but there's also enterprises and other organizations that really want to use the same model and when we initially released actions we didn't offer the ability to trigger pull request, workflows from forks of private repos, and we.

A

Didn't do this.

B

A

So, basically, inside an enterprise, I would have to branch right, create feature branches and then merge them um and it's out on public repositories. I could use the open source model of forking things out.

B

Yes, that's exactly right, and while that works great, the branch model works works very well. There's enterprises that simply want to work in that fork and pull model. So when we originally released actions, we decided not to implement that, and the reason is is by forking that repo and running actions, you kind of uh give the enterprise a little bit less control over what's happening, um and so they need the ability to to lock down and say. Yes, we can do this or no.

B

We can't do that, and so to fix this, we decided to implement some new settings for enterprises to turn these features on and off, and so back in august we released some new settings for private repository forks and if you go into your organization settings or your enterprise settings you'll see these new settings. Where you can say, I want to be able to run workflows on for pull requests.

B

This only applies to private repos and also the ability to send right tokens to those workflows, as well as send secrets to those workflows, and this is significant because in the case of public repos, we never send a writable token or secrets to fork pull requests. This is because you have code coming from an unknown person and we want to see limit the potential uh for them to steal information and access things. They shouldn't have access to.

A

But in enterprises.

B

And organizations, if for customers that want to work in the fork and pull model, they really want it to work in the exact same way. It would, if I had, were able to commit directly to the repo and create a branch, and so these settings allow them to configure that.

A

So you basically now have full control over enabling and disabling these features, so you can choose the way that you want your enterprise to work around these things.

B

Exactly so, if I go look at this enterprise or this organization, I have set up, and I go look at the settings for this particular repo right now and I look under actions. I've said that this one does not let me run for pull requests, and so let's do a quick test here. So if I go to my fork, so I've got a fork of that particular repo.

B

I'm going to go to the readme file, just edit this guy real, quick.

B

Take out some content create a new branch call. It patch one propose these changes.

B

And in this case I'm actually gonna go click here and say you know. I want to compare and pull request, I'm going to add to our base repository here. This branch.

B

Head base, I don't actually want the base to be mastered in this case, create my pull request.

B

And we can see what's going to happen, is now we're back in fib tools, but no workflows are running. If we go look at actions, there hasn't been anything triggered, so I've got no no workflow happening.

B

So what I'm going to do is go into my settings, go to actions and say you know what I want to be able to run and go ahead and set these settings. We'll save that.

B

So let's go ahead and make a change to this file and open up a pull request, and we should see now that we have those settings set. Our pull requests run so we'll test more. We will create a new branch called patch. Three propose these changes.

B

Now, in this case, it's going to ask me to merge directly up to master, but I want to do is: go and open up a pull request back up to the base repo, so we're going to go back up to fib tools here with our patch create this pull request.

B

In this case, we've created the pull request in the upstream repo and we should see a run trigger. So now we've seen a run trigger to update the readme. So in the last time we updated it, there was no run trigger. In this case we see my updated patch two and were triggered a run of all these different uh jobs that are gonna. Validate that I didn't break anything and then eventually, let me merge, which.

A

By the way, I have to mention that this is an awesome feature that you can run on the matrix and choose all different os to basically run your ci build on and make sure that it's all working.

B

Yeah, it's another great feature: it's been there since day, one. It gives you a lot of flexibility and the ability to really test, in this case, across all I'm testing across three different operating systems and three different versions of node.

A

Which I know some folks who are absolutely in love with this just for this feature, because they don't have to have like a mac under their desk now to test these things, so that's kind of fantastic um advantage for enterprises all right. So um thank you for showing us these features. um So one more thing that I wanted to ask you about, so I know that github actions uh allows uh open source projects to run some basically hosted runners for free. So do you want to tell us about that too?.

B

Sure uh so github actions offers the free usage of actions to open source projects and it's effectively unlimited. We do have some uh terms of service that allow for fair use. We really expect you guys to be using this to run your ci and run your test and do things that are really about maintaining your repos.

B

We also actually offer some amount of free or included run time on our hosted runners for your private repos depending on. If you have team or enterprise, you get a different amount, you can go check out the documentation for those details.

A

And I think that we just recently added um the feature that you must enable actions to actually run on open source projects too.

B

So that not exactly so what we did is in the case, uh we just talked about the fork workflow as an interesting example.

B

So there's a lot of cases that we saw where customers would fork some project into their their or their account, and then they would maybe play with it a little bit then kind of let it languish, and in many of these cases these projects had scheduled workflows, and so we would start to see thousands and thousands of just scheduled workflows running that are really doing nothing, because these are repos that are just not active, and so we have explicitly uh had added a setting that, basically, if you fork a project, you have to enable scheduled workflows explicitly, and this is really to protect the community.

B

You know: compute resources are finite, they're, definitely not infinite. We want to make sure that we can provide the best service we can to the open source community and so we're doing small changes like this to really keep things in what we call fair use and- and we know in this case that most people aren't trying to abuse it. They just didn't know right. It was an accident, so we want to make sure that uh it's not it's less likely that somebody does something unintentional that that hurts the community.

A

I see yeah there's nothing more permanent than temporary things right. The test lives on forever. um So thank you so much for leading the charge on building uh the actions features and thank you so much for spending time with me today um telling us about um how this works. So this has been get up check out and please hit the subscribe button for more similar videos.

A

B

Bye, thank you. Sasha.