GitHub GitHub Checkout, 19 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitHub Actions: Limit workflow runs & Control permissions for GITHUB_TOKEN

Description

GitHub Actions now supports a concurrency key at both the workflow and job level that will ensure that only a single run or job is in progress.

https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/

GitHub Actions now lets you control the permissions granted to the GITHUB_TOKEN secret.

https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

What's up y'all, I'm b dougie and I've got a github feature for you to check out. So if you've been following the github change log and all the different features we've been shipping, you have noticed. We've been shipping a lot here at github and this video series, the github checkout series, is a place for you to meet the people behind the features and speaking of I've got chris patterson the talk about github action. So chris, why don't you take it away? Thanks.

B

For the intro bw so today we're going to talk about actually three features uh with github actions that I think are really cool and kind of work together to enable you to just further improve your workflow automation.

B

So the first one is uh really more of a set of features that we actually first announced back at universe and have been steadily improving since then, which are really geared around improving your continuous delivery workflows. Now, from the day github actions launched, you could absolutely drive deployments and continuous delivery through it. But in order to have you know a continuous delivery workflow that has some of the sort of more compliance or control features that people want.

B

You know we were definitely missing a few things so at universe we introduced this new concept of environments and, specifically environment protection rules. So if you go to your settings tab, you can see here. I've got three different environments for this particular application. I've got a review lab, which is kind of where all the pr's go. We'll take a look at how that happens. We've got a staging environment, a production environment and you can see in this production environment. I've got two protection rules and one secret.

B

So if I click here, we can see that this environment, in order to deploy to it, has what we call required reviewers and basically, what that says is in order for any job. That's in my actions, workflow that wants to deploy to this environment to run one of these people or a team has to approve it and further.

B

I've said that, in order for jobs to deploy to this environment for my workflow, they have to come from the main branch, and so these kind of two protection rules work together to make sure that only code, that's made it to maine. I.E, has passed through code review and whatever other checks. I have on my pull requests and has been okayed by one of the environment. Reviewers gets deployed.

B

Now, along with that you'll see, I've got an environment scoped secret, so actions when we shipped over over a year ago has always had secrets, and you know it's a great way to use encrypted values as part of your workflow.

B

But in order to have a great, continuous delivery workflow you really want to have the ability to have a secret that says is: is accessible for deploying to say development, environments or review labs, um but also you want to have a different secret that maybe has a higher privilege or targets a different account or subscription uh for deploying from say production, and so these features work together to really uh help you have that compliant or or you know, secure continuous delivery workflow. So let's take a quick look at how I actually make that happen.

B

So if I go look at my code, I've got a deployment workflow here and you can see it's got a few different jobs. I've got one that builds a container that actually has my app uses. A few of our features. Caching uses some great actions from the community like the stalker buildex action, but the first thing you'll see here is I've got my deployment review, and so what this does is basically on every pull request event.

B

It will create a new slot in the case of azure web apps for the particular version of the application and give me a view of that. So I can go review it directly from my pull request. It integrates nicely you'll get a box that shows you, you can click on the view the deployment and then after I merge my pull request and I'll get a push event, and you can see that in this case I've got deployed to staging, which only runs.

B

If I happen to be on main and then this deploys my app to a staging environment, and then I've got one that comes after that. That's dependent says it has to go to staging first, so it needs to deploy to staging which deploys to production. And so, if I go look at a run for this particular workflow, I can see I've got one here. That says: hey I'm going to merge from pull request 13..

B

So I want to take a look at that and I can see here right away that the build was successful and I've got a successful deployment to staging so right. From this view, I can click here, go take a look at the app make sure things are working properly, make sure whatever change looks good and then, as one of the required reviewers, I can simply click review deployments.

B

I can say yep go ahead, you know, deploy to production, click approve and deploy, and that will kick off the job that will deploy my version of the app to production, and so I can build out these different workflows. I can use all of the great features of actions to really create a very complex and very secure, continuous toolbar workflow.

B

Now one more thing that we've noticed and certainly got some feedback on was this is great, except for what happens if I have a busy repository and I've got a bunch of people merging prs, how do I make sure that only the latest code is deployed to production, and maybe only one uh deployment is happening to production at any given time, so in the next few days, we're introducing a new feature that we call uh serialization or or a new key in the workflow that we that's called concurrency.

B

And so, if I go look here, real quick I'll take a look at a workflow in one of our test. Repos that uses this new concurrency key and essentially what it does is. It lets me specify a string which we call a concurrency group, and this is a repo scoped string, and so in this case, only one of these workflows, that's deployed to production. Workflow can run at any given time for the concurrency group prod deploy, and I can actually specify the concurrency group at the world overall workflow or at the individual job level.

B

And so what that can, let me do is, if I specified say at the job level- and I say my concurrency key- is production whenever the system goes to start, that job it'll look to see if there's any jobs that are already running against that particular concurrency group, and if there are, it will put this next job in a pending state and as soon as the previous job completes the next one will start.

B

The system will also always make sure there's only one job in the pending state. So you're, always in the case of like this production deployment scenario, you're always deploying the latest code. So if another one comes in well, I've got one pending. It will cancel that pending job and then you know, pin the next one, and so it really can help you have that very serialized. You know deployment to a particular environment and make sure always the latest code is deploying in this case now.

B

You can actually use this for a number of different scenarios, because it's a pretty generic feature. So we've implemented one more case where you can actually control that behavior I mentioned so. I talked about how we'll cancel pending. Well, I can also cancel. Have it cancel in progress run?

B

So if we take this example where I've got a pull request, workflow- and I always want to make sure that only one workflow is running for a given pull request at a time and and if I update that pull request with say a new code, I want to kill anything, that's running and just start the latest ones, because it's you know letting say, potentially very long test suites run um just burns.

B

Compute burns your minutes and, and you just don't need them running, and so what I can do here is I can set the group to say in this case. What I would probably do is set the group to something like github dot, head ref, and so whatever the head ref is for the pr that's gonna, be my concurrency group and I'm gonna tell it to cancel in progress, and so what that'll do is whenever a pull request is triggers. This particular workflow we'll look at the concurrency group head ref, we'll start it.

B

If another update another event comes in for the pull request for the same group, we will cancel anything, that's running and start the next one, so you can really have you know, conserve your minutes and make sure you only have that say one thing running for the pull request. So we really think this concurrency feature is super useful for a variety of different scenarios.

B

The last thing I want to talk about is a new another feature. We've added to really help you improve the security of your workflows, so most people. When you talk about security, you always want to think about least access, and so, when we launched github actions, we know knew we wanted a generic automation platform that people could do all sorts of things on with github.

B

However, to do that, that means we needed some way of providing you authentication back to the repository to update, prs or add labels or even push push code back. However, there's so many cases where a workflow simply doesn't need those broad permissions, and so we've added a new permissions key that you can actually set again at the overall workflow or the individual job level.

B

That will let you control the individual permissions that the token the github token secret, that we generate automatically for you has, and so this particular case I've got a very basic workflow that cleans up my review, lab environment and I've only given it the ability to read the source, because it doesn't need to do anything else, and so this can allow you to do some interesting things like. Maybe you have a one job in your workflow that uh needs to have you maybe run something? That's untrusted and you want to give it very narrow access.

B

I don't want any any um any ability to do anything other than read the code, and then you could have a second job. That does something that's more trusted, and so you give it a broader set of access.

B

So we think that you can combine these different permissions in different ways to really make sure your workflows only do what they need to do and further one of the things that we're currently working on that we hope to roll out uh the week of the 19th is the ability to actually set a setting at the organization and repository level that forces the baseline scenario to be code read only, and so you can basically set up github actions such that, instead of the token having broad permissions, it has very narrow permissions always and then you explicitly elevate up in the workflow itself.

B

You know all logs log the exact permissions the workflow gets now, so you can see that and we also push this into the audit log. So you really have a lot of your control and a lot of understanding of exactly what your workflow is doing and exactly what those permissions are, and so we think these are some great features uh that really help improve the overall security of actions that help you have good, secure compliance continuously, workflows and also just another really nice feature to help. You make your workflows more powerful.

A

That is amazing, you covered so many different features and some of them- I didn't even know about until this call right now, so I'm looking forward to get my hands on these permissions as well as some of the other uh features. uh But I did have one question: where can people keep up keep tabs on the changes to get of actions, as well as ask questions and uh get their concerns raised.

B

So it's a great question. First off the best place to keep track of. What's coming is the change log. The get we put. All of these new features go into the get getup change log. They should all have document links to documentation and also the changelog now has tags, which is a new thing, we've added recently, so you can easily go through and you can click and filter to just changes for actions. If that's all you care about.

B

As far as talking to the product team or providing feedback, the github community forum for actions under code, the cloud is a great place. We have an awesome community there that does great job to answer questions I myself spend at least an hour or two every week answering questions there, and I also try to keep track of when things are asked for and when we ship them to go back and comment against those threads to let you know.

A

Yeah yeah and I have to myself- I have to get back in there. I've got some tabs open of questions that I have answers for because, as you know, I do lots of action works um and I'm super excited to add this. These features to my workflow, so chris thanks for your time and uh folks, uh if you enjoyed this, let us know below. uh If you have questions head over to community forum and if you want to watch the next video stick.

A