GitHub Universe 2015 - Deploy, 4 Feb 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Integrating with the GitHub API - GitHub Universe 2015

Description

GitHub’s API is used by organizations around the world to integrate their tools and processes with GitHub. During this session, Kyle Daigle will focus on how GitHub and other organizations use the GitHub's API and webhooks to enhance their existing workflows within GitHub and allow for some new ones too.

Examples of how GitHub uses our own platform that we’ll work through:
+ How to get started with the GitHub API in your organization.
+ Create tracking issues from Nagios alerts that include diagnostic information, and alert engineers with team mentions.
+ Track test output, code coverage, and more with commit statuses.
+ Automate repository setup with organization webhooks.
+ Track deployments of pull requests across multiple environments and deployment schemes.

About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.

For more information on GitHub Universe, check the website:
http://githubuniverse.com

A

My name is Kyle bagel I am in a platform, engineer, I hope, I work on API and web looks. Who here has used the API directly, either for fun or for work? Okay, great? How many people say they integrate with someone that uses the API? Maybe a CI provider, an issue tracker.

A

Main goal right now: it's basically I'm gonna show you how we've used the API to integrate github the engineering organization into github the product, and so most of the tips that I'm gonna show. You today are things that you can use at your own organizations to sort of level up your ability to integrate cross product with different platforms and then some tips on kind of how we've baked it into operational work and basically across the entire organization.

A

So a lot of things that I'm up to show you are basically through pain that we fill in our own process. The API is that we use are all public API s. We don't have a secret API to do the things that we do every day to build github in almost all of these tools have a Hugh bot component or chat ops, so Hugh bot, if you're not familiar, is an open source project that we run.

A

That allows you to use chat, to say, deploy to check, CI statuses, to search users, to run console commands to check up on my sequel, databases so on and so forth. So I'm not gonna cover that too much, but I wanted to point it out, because it's a crucial part of how we use the API.

A

We develop that github, and so, if you haven't used that or if you have a chat to work, but you don't use a sort of bot to help you do things, definitely check Hugh bot out because it'll definitely level up your ability to use the API to do github related things.

A

So this is what I'm gonna cover today, I'm gonna very quickly. Show you how to get started on the API.

A

We're gonna automate, some repository setup using organization web hooks track and test output for using commit statuses, show you how to use deploy within the github API and then sort of tie that all together and show you how we use our API along with Maggio's, to help make sure that the engineering organization at github is working really closely with the operational side of github. When things don't go exactly how we planned and then I'm going to answer any questions that you have at the end.

A

So hopefully we can get through some stuff and I can answer your specific questions, while we're all still here so getting started with the API most of the documentation. You'll need both in API documents and sort of getting started. Documents are at developer, github com, so I'm gonna show you some things that I might gloss over a little bit. If you have more questions about specific, you can always go back here.

A

The first thing started with the API. Is you need a token? A token is your way to work with our API to get the resources that you have access to. We do allow you to use basic off, but we don't prefer it, and so I'm gonna show you how to get a personal access token, similar to an OAuth token, if you were to work with a third party or within an application, your own organization.

A

This is a quick and easy way to get a token to call the API and and just get started when you're trying to figure out how you want to use our features. So this is within the settings page in your github account and within that we're gonna. Allow you to basically build the token and choose the Scopes of your token, which is a whitelist level of permissions that you can say.

A

Yes, I would like you to have access to all of my repositories or yes, I'd, like you to be able to read my public keys, and so once you have this and you fill this little form up. You're gonna get a token and, in my example, just abc123 running a simple curl command like this will give you the ability to see the token works right. This is the very first base set. It looks like a lot of people here have done something with the our API or another API.

A

So I'm, not really gonna belabor the point here. But if you haven't it's very simple- and this is how you can get started.

A

Github supports some client libraries for the sake of my example: I'm gonna be showing you Ruby ish things.

A

Sometimes I might cheat a little bit on the syntax just to make it more understandable if you're familiar with a ruby but get supports a ruby, client, an objective-c client and a dotnet client. The community has tons of other clients, though, so, if your language of choice isn't showing up here, it's likely that there's an open source project that can get you where you need to go with using our API alright. So that's the quick, the fast once-over on how to get started now.

A

We're gonna start diving into how we use it, how we use the API internally and how you can use it. These things are sort of gonna build on top of each other. This is like a art survey course, if you've ever taken one of those in college where it's like you know, take this for granted now I'm going to show you some things, that's sort of what we're gonna do here so organization web hooks. Well, the first question might be for a lot of people.

A

Is you know how do web hooks work right and so a web hook is basically a very simple action. We're in github something happens. I create a pull request that comments on an issue. I close a pull request, I merge a branch github can send an event from us to your server containing a payload of information that you can use to build. What you need on your side and so in this example. It's very simple. It's just an HTTP POST.

A

It looks it can look like a forum post if you like it could just look like a body of JSON, but once you get it on your side, you can use that information to call back to the API to update it, to call an internal system to kick off a deployment, and this is one of the major parts of the API. It's our outbound API. It's how we're letting you know right away that things are happening. So that way, you don't have to pull us right. Contact us over and over again saying: hey.

A

What's changed, hey, what's changed, hey? What's change the web hooks allow you to get that information as it happens, and so how do you organizational web hooks work? So if we have a web hook, that's sending events over github as a feature where you can install a web hook at the organization level, and so for most of us an organization is our company at larger companies or if you use github Enterprise, it might be your division or your area or your team.

A

But what you can do is you can install one web hook for all the repositories that you have in your organization instead of doing it by repository, we still offer repository based web hooks. You can set them up repo by repo, but this way you can get a ton of different events that aren't necessarily available in a repo context. Like a new person joined the organization, maybe you're onboarding a new teammate. You can get an event for that.

A

So this is an example of what the payload looks like once you get it on your side. This is the JSON example. You can see they're pretty well, hydrated they're, not very skinny payloads, primarily there's a lot of uses first say chat or you know messaging tools where you want to have all the information you need just sort of reformat it and send it along. So there's a lot of information in here. It'll show you basically the action that was taken. The repository some information about the repository who took this action.

A

What organization was this action? A part of it contains a ton of information, and so you can get it as JSON or you can get it Foreman coded. So it'll look like a forum post on your server side to set this up. You can set it up within both the organization and within the repository in the settings view of each of those. The forum is super simple. It starts to look like this where's, the URL. What content type would you like?

A

Would you like us to use a secret, so we can sign it and know that it's actually coming from us and then the last step is choosing the events that you want. So you can get all of them. You can get just the push event anytime, someone pushes code up to your git repository or you can get the variety of events here, and so the ones that I've chosen right now are the organization's specific ones which anytime someone's are removed to a team and any time a repository is created within a team.

A

So I'll get into specifics about why those are valuable, but but this is sort of the base setup for a web hook. You can also do this via the API. So, if you're doing any sort of developer, enablement or operations work- and you don't want to go one by one in every single repository or organization- you can do all this setup via the API.

A

So why do you care the main thing that I think organization web hooks allow you to do? Is it allows you to stay in sync with team memberships in repository creations? So anyone when you set up a new repository has anyone have to spend a bunch of time getting it set up like the other repositories in your account? Does that ever happen? If it set enough to point at a new chat room or anything like that, yeah, and so what this can allow you to do now is you're gonna have an organization webhook, that's listening!

A

For every time a new repository happens and then, once that new repository comes in, you can receive a post at this webhooks urls. This is this looks like Sinatra in Ruby. If anyone's familiar, find a team ID right. Maybe it's the engineering organization. Maybe it's a group of trusted admins, maybe its operations. Maybe it's a bunch of teams and then use the API, so client dot. Add team repository is part of those github supported libraries that I showed you. You can make a really simple call here.

A

So now, every single time you start a new repository. Someone in your organization doesn't have to go through and go alright. Alright, now we're gonna add the employees team and then we have to add this team and then we'd have to add the slack web hook and then to make sure it's talking to our CI and so on before. If you can do this all just via a web hook, and so in some Enterprise organizations, this could include letting a third-party compliance. Some know it could include syncing memberships with another system.

A

So if you want to use github as your primary authentication mechanism, you could then go and say alright CI tool make sure you let this person login or okay internal system, this new person or this new repository was created. You should know about it right now, and so this webhook piece sort of ties in to the next set of different tools that you can do that. Your tasks that you can take with the API. The important thing to remember is just it's an a pound-- API.

A

It has a ton of events and so I invite you to go to developer document of see the different events that you might want to look at, because we cover a ton of them, and this is how a lot of our integrators keep in sync, with our data right instead of pulling rate limits or still a thing, and so you can't just spend the time pulling. This is a great solution for that. Alright, so recovering webhooks, now we're gonna get into statuses and how github sort of overloads them and uses them for some different things.

A

Besides simple CI, so you might be asking how do statuses work, so this is an example of rails rails. This is just the PR that was someone made. I took a screenshot of and at the very bottom of the page, there you'll see that there's the little green check mark that says all as well and that Travis CI the Travis CI build past and so that little piece right. There is a status if you've used continuous integration or any tools like Jenkins or code ship or Travis or circle.

A

Any of those tools to build your code after every push, they're likely using statuses to do that, and so this is the simple use case right people using CI, any sort of automatic building raise your hands, raise your hands, ok, awesome, and so let's see what that actually looks, looks like on our side. So this is still for. You you'd be hosting this in your on one of your server again you're.

A

Just gonna get a post from a web hook right in that post will be probably a push event every time someone pushes up code, you probably want to make sure that that code is gonna, compile or run correctly, so the first step is pulling out the repository. The second step is pulling out the SHA, the unique identifier and you get repository for that commit, and then you have your options and the options are basically saying the context. What do I want to call this check right? It might be CI, it might be a demo.

A

You can give it a target URL so that you have the ability to say win. This builds. What does it look like? What do the logs say and then a description, and this will be visible to end-user again, we call client, which is just using our internal library and create su3 sha, and then saying it's pending we're starting to do this build right. Now we don't have a result yet, and so, if you haven't seen these happening, I just took a quick, a couple quick screen shot. So this is a pending commit a failed, commit.

A

Pretty simple right in a passing commit this will all show up in the UI, both in the commit use in your PRS, as well as at the very bottom in the big box that has the merge button in it, and so now, how can we overload commit statuses right? Ci is why they were built, but there's a ton of other interesting use cases for it. So at github we have to run a bunch of different builds. We run the builds on the app we run, the builds at the Enterprise version.

A

We run the builds at the second Enterprise version, and then we have something that we call github set up and so I'm sure this has happened to almost everyone. But if you're an engineer join a new company and they're like just pull it, let's pull the repo down and just you know, get started run.

A

You know whatever the language specific things that you need to do to get going, so rape DB migrate if you're in rails whatever, and it all goes to hell right and it never works correctly ever and so what we did was we created a simple thing that on every push, we're gonna, bootstrap a whole new environment from beginning to end, and so what this allows us to know that every time we bring on a new engineer at github that if again I'm gonna use rails, specific examples, because github is primarily built in rails in Ruby.

A

This EEMA isn't out of date, and it's complaining that, oh, we don't know what commit or excuse me. We don't know what migration version you should be running or there's a gem dependency that isn't checked into the repo, but we just assume you have it because the person who committed it had it, and so, let's just hope it all works out, and so you can see a pretty simple example at the top. We're just gonna do what we did the last time. We're gonna create a status with the pending status.

A

Saying: okay, we're gonna start this at github we have a set of standard scripts that every repository has and in this example we'll say, stripped bootstrap, meaning, let's start from the very beginning, we're going to get the dependencies. We need we're going to install the gems.

A

We need create the databases and all of that and then, depending on the success of that, we can say yep, it worked or no, it didn't, or we have no frickin clue what happened, error right and so for your I would I would love for you to think with that script because that's usually the first step. Maybe there is no script right, maybe you're! Just it's just gonna read me or maybe it's just you know, Godspeed I hope you know how to get this going right.

A

So the first step might be that script piece, but once you have that script piece now you can use statuses to do for more than just CI. A lot of other open-source projects will use statuses for contributor license agreements. Cla agreements has this person signed the CLA enterprise organizations or compliance. Heavy organizations can use statuses to say yep. All of these commits are correct. They use the correct message format. The contributor has an email address, all of that sort of thing.

A

All of that can be used and shown in the commit statuses, and now we statuses, we allow you to say this status must pass in order for me to merge this, and so you can decide what statuses, maybe it's all of them. Maybe it's only a couple of them, but you can decide which of those you. You would need.

A

So now we have statuses. We know the code is good to go out, so we can talk about deployments and so how do deployments work at github? We show the deployments in the pull request, and so this is a really great way if you use a github style flow, where you're using pull requests primarily to make sure that you always have a history of the actions that were take on that code, and so you can say yes, it was reviewed.

A

Yes, the CI passed, yes, Kyle pushed it to staging before he pushed it to production right, because if you do that, everything will be tracked in the PR, and so here it's just showing an example from jake boxer saying that he deployed it into production and waited some time, and then he merged the PR back into the stur.

A

So how do deployments work at github a lot of these features? You won't see in the UI unless you use them so things like statuses deployments, only show up if you have them so basically how a deployments work. You have to trigger a deployment event and that usually happens via the epi meaning you could get a push. You could get action a webhook or this could be a chat command. This could be a button in your UI, where you make a simple API call to github to say: I would like to create a deployment event.

A

That event then goes back out via web hooks. So this could go to your servers. This could go to a third-party service like Heroku AWS asher, where they receive this deployment event. Saying I'm asking you to deploy this code. They'll start deploying it and then report back success or failure with logs. So it starts with an API call. Api call triggers a web hook, you receive it, you decide how to act. Generally, we talk in web parlance, but the very same thing could be done with native applications.

A

Deployment might just be a build where you're gonna create a binary and upload it somewhere. You know, it'd be an iOS distribution, there's a lot more options than just the web, which you know a lot of times. People think this feature is primarily for that.

A

So what does this look like so to deploy and build your projects? It looks very Flur in a way to doing statuses. So again, we're gonna pull up the obvious stuff. We're gonna pull out the repository. We're gonna, pull out the ref, we're gonna say what ployment? What shot or reference are we actually going to be deploying here? That could be a branch name that could be an actual shot, could be a tag, and then we have a bunch of options. The first option is tasks.

A

This is something that you can you can provide to us. You don't have to to say I would like a deployment to happen using this command right. You would use this on your side to say: ok, I'm gonna, take the task and run that command that could be like deploy it just to staging. It could be deploy it with these command line. Arguments. Anything like that. That's completely controllable and usable by you.

A

There is the auto, merge and so auto. Merge says when I request this deployment make sure I'm up to with my default branch. So, generally speaking, and get land, that's master. If you have set up a different default branch in github, develop branch production branch, anything like that we'll use that required contexts, and so, if you remember back the status demonstration, we said the velocity demo was the context that I was using, and so we can say only deploy this if these statuses have passed right, so you can kind of protect yourself.

A

Just in case you know, there's an engineer missed the failing status or you know you don't realize that something failed. This will protect. You it'll just come back and say no, you can give it a payload again. This is basically for you. So if you are in a native environment or you have to decide what platforms you actually wanted, the ploy against the payload would be a place where you can do a key value and say this is what I would like you know.

A

These are the settings that I need for this environment, the environments, pretty simple right production staging if you use something like Kuroko's review, apps, which are really really cool, and if you don't know anything about them, definitely talk to them about it. They can have different environments here there for those and then the description. The description is just the human readable version of what we're talking about again at the very bottom. You can see the create deployment call again using the client.

A

This is basically the first step to getting a deployment out and so at github we do all our deployments via chat, slash, deploy repo named branch name to environment name and then, if there's a problem with that, the results will come back the API and goes back into chat and other organizations that might be a web UI. It might be a button click if you're using the github API to do this, but there's a bunch of different options around that.

A

So once you ask for a deploy, the deploy actually has to happen right and, as appointment can fail in a variety of interesting ways and so again we're back to web hooks, and so you make the deployment and then a web web hook. Event goes out saying all right all you systems that are listening. This person would like a deployment of this ref, and so you can see that we pull out the repository again, the Shaw, the deployment URL that we specified and then we're gonna say script deploy right.

A

So originally, if you look I mentioned saying: okay, you can set the task. You might just want to shell out and say: okay, do this task or run this run this script with these options attached to it, but for this example, it's just script deploy depending on your situation. That might be a different call and then again my ruby ish. If it succeeded, you can create a deployment status saying that it succeeded.

A

If not, you can say that it failed, and so the benefit of this is that when you deploy something- and it doesn't work correctly now- your PR will say Kyle deploy to production and it failed and failed will be linked over to the logs that were that were generated from it. And if it succeeded then even better. You know, then, you just have a link to a reference of maybe we're all the shah's or at maybe when all the dependencies are at and you can track that completely and so at github.

A

We have now the ability for us to deploy to production in stages right so that obviously we're not just gonna put the code out and hope that it all just works. We can say alright, let's just do a tiny, tiny subset and you can see that in the PR. So that way, when anyone comes back later, if there were problems or if things went, okay, the PR is that complete record.

A

And then yesterday we released the integrations directory and so there's a ton of partners. This is a very small subset of who we who exists, but it's currently in the directory, we'll be adding more and so, like I said, a lot of people use AWS code deploy Heroku has their new pipelines feature, they also have their review apps. That way, every single PR can have an immediate app without having to do any work. It's a very cool feature.

A

Heroku is an option for you and then a lot of the CI providers will also deployments for you, and so all of these are at some point, reporting back to gab in the you in the UI as well. So you get that benefit of having it all in the PR, but you're not going to have to set it up all on your own. So you don't have to feel like.

A

This is something that you need to go out and build on your own, it's possible or probable that one of the tools or systems that you use can already provide this for you, okay, so the last piece I'm going to show you before we hopefully answer some of your questions is sort of a mishmash of all everything. I just showed you in one place.

A

Anyone work in operations or sis admins, or anything that yeah okay, awesome, and so this was built by an excellent engineer, slash to admin Hecate hub we're trying to solve a problem where alerts would happen and we get those notifications, but there wasn't an easy way to collaborate on those alerts across teams across functions. So across engineering and operations across engineering and systems.

A

And so excuse some of the redacted information, but what this allows us to do is we have a two internal tool called haystack, which is similar to any sort of error, tracking tool like honey badger if you've used that or break where, when errors happen, a central location and what we do is we track their velocity and when the velocity gets too high. There's too many errors per minute. Someone from the engineering organization, who's on call will get paged and not just operations.

A

So the important thing in this example is at the very bottom and so sorry, it's kind of low. It's a CC at github, slash, github, haystack on call, and so that is a team at github, and so your organization can have a multitude of teams and some companies only do a few for engineering and operations and marketing. Let's say at github, there's a lot of specialty teams. So there's github, slash platform, github, slash hooks to deal with web hooks related things, and so, when these things come in now we're immediately mentioning those teams.

A

This doesn't replace something like pager duty or an actual phone call. That says, wake up the things broke in, but what this allows us to do is in the morning, if, let's say we weren't on call we're all able to see what happened and answer and say: okay, yes, I know why that happened. This is what happened, etc.

A

And so that initial set was just a simple issue: creation via the API. Now what we do is we actually comment on that same issue using graphite, so we're using the github API to generate a issue comment, a link to a bunch of graphite graphs and those graphite graphs are a shot in time. You know when this alert happened. This is what the time before and up until now looked like it. So it can load in a bunch of different other information, so we can load in playbook links.

A

So if we had written documentation in another github repository that information can be pulled in as well, so it can say okay, this is what the engineer who built the system said. You should do when everything went to hell right and that again can use the API and then other diagnosing can happen in chat again gives a huge chat user, and so we can use mentions from chat back into these issue comments to sort of track. What happened.

A

And so this is the awesome gnarly command that gets run when something happens in Nagios. That needs to be reported, and so it basically sets a variety of environment variables, and then we call that in the middle there gh9 zap update, alert or actually posting to this little application that we run that does these API calls for us with the information and I'm gonna post, my slides after the talk so don't feel like you know, you have to decipher this from your iPhone, and so this is what the app looks like we're, obviously very simplified.

A

But basically it's saying: okay, we're gonna, get this post from Maggio's the app takes it with the alert parameters that were sent in the environment, the error that happened, how many times the check failed and all of that and then do a simple response with a 201. So it's basically just gonna, say: okay yep got it and then now we start talk to the API. So now that we have the alert in a background queue so that way, we're not holding that web of you know that web of open 9s goes and says.

A

Ok, let's create an issue for this alert that got triggered and that issue will use a template holding the pain information. Ok, we want to. We want to see, see the pins team. We want to see, see the playbook that happened. We want to see, see or paste in the information, that's specific from that alert and then that whole piece is ultimately what generates, and so once we have this information again we're able to essentially go through and and have a one-stop shop to talk about the actual check that failed.

A

We closed the issue once the check passes, so it's not just sort of lingering open. You may choose for your organization not to do that, but that all happens back through the same flow that I just showed you and then we're able to basically look at look at these in a weekly context and say: okay, why did this check pass? Why did this check fail? How did engineering respond? How did ops respond, and so the cool thing about this?

A

Is it's just all automatic, even that weekly update just uses the API to do to do the work that we need.

A

So I went through three examples, plus explaining webhooks on basically how github operates using the API. We have some really great documentation at developer.android.com.

A

The basic use cases how to get authentication if you're interested in building an integration against github for fun and profit, and not just for work reasons we can cover basically how you would want to authenticate and actually build an OAuth application instead of just using a personal access token. All of that is probably better covered there than in a sock, and so I definitely invite you to take a look at that.

A

We have a fair amount of time left for questions and questions and answers about the API, the platform, how it works. Anything like that and so I'm happy to answer your questions now and I think we're going to do it where you can speak very loudly and I'll repeat it for the live stream. So awesome if you have any questions or you'd like to follow me on Twitter or github I'm at Kay Daigle. Thank you very much. Everybody.

A

All right so questions.

A

Sure so the question was basically: can you describe a bit more about the deployments API and how it specifically used that github when we deploy so at github, like I, said we use chat primarily and so for me as an engineer, I'll go into chat and I'll type, slash, deploy, github the repository, slash branch to staging weapons. There is that first step in the deployments piece me just back up through it. It's ohyou bot will then make HTTP requests to the API saying start a deployment.

A

This branch, this environment Kyle asked for that, and so once that happens, at github we're gonna take a web hook like I said, except it's gonna go basically back to us, not github. The public API github the. How does github deploy its code, and so you might have to build that for your particular environment, basically saying receive this run the deployment whatever that looks like for you and and then report back for a lot of you.

A

This might just be Heroku or Azure or code deploy or any of the other sort of tools that already have this stuff baked in, but the only custom Keese. Really besides that initial API request the create a deployment event is the service square? It's saying, okay receive this truly do the deployment which is too specific to everyone's own. You know deployment environments, but yeah. The all that Hugh bot is doing behind the scenes is basically starting the starting the set of dominoes. You know saying: okay, create the deployment event yeah.

A

Where would people find that if they were looking okay great so what was your name Chris? Okay, so Chris just mentioned that he just recently wrote a book for a Reilly building, get building building tools of github. So.

A

Awesome so it's about building testable API applications built on top of github, so it just went into early access. So it sounds like if you go to O'reilly and you and you and you search for that book. You should be able to get it awesome thanks. Chris yeah.

A

So it'll depend on the ref that you've chosen I'm sorry.

A

So the question was: if you have three PRS, that you've already merged to master and then you go and are doing a deploy, will they each have the deployment event marked in it and so I believe it's gonna matter quite a bit about how to how what ref, you're choosing so assuming you're deploying master I, don't believe that each PR will have it in there because it's this is primarily built for the flow of you know, deploying the individual branches and then merging it back to master I know that get the company's name.

A

So I don't want to be wrong, but what they do is they essentially do something very similar to this either o their PR? That can track like this. Is the history of code? That's going out or create an issue for that deployment. If you're doing safety is our weekly deploys or you know something? That's not / PR basis, there's a couple different ways that you can either use the API to create issues to do that or have one PR that will encapsulate the changes.

A

That is that are going out to production, but it will depend on what ref, you're, choosing and back a step. But in this piece here at the top, the ref that you're starting out with yeah.

A

And so so, he was very kind to ask me this last night and I couldn't remember the answer, and so I said alright. I'm gonna go make sure I know this answer, so I don't look like an ass in front of everyone. Luckily, thank you for cheating. The question is: if you're using a forking workflow, like is mainly done, an open-source organizations prefer that engineers work the repositories that way the main repository stays completely clean and then, if you issue a PR over here back to the main repository, how do you keep this repository tested?

A

How do you keep the test updated as this PR and the separate branch works, and so the event that I forgot about was theirs.

A

The event is the pull request event with an action of synchronized and the the synchronized action is the piece that's saying: okay, this was updated. The coat the get Shaw's were changed and so it'll send you an event that says action synchronized with the new Shaw and so that you'll that you'll be able to use to actually say.

A

Okay, I need to run this again for this other PR that or for this other you know repository, that's not in my complete control, and so we discussed last night about how, if you use Travis for open source work, they they will build PRS if you let them for outside repositories for Forks and and that's the event in action that they use to do that. No problem awesome any other questions. Yep.

A

So the question was what about branch protections, and so the P I will still respect, though, if you set up a branch, that's been protected or or has it work or via required statuses and you're, trying to take an action where either one of those won't you know be allowed. The API will return, 422 I believe with the response saying this branch can't be, you know, can't be deployed or can't be merged, or the data can't be changed in it, because this is a protected branch or this is a protected status.

A

A

No, the is I want to protect a branch by the API, not currently yeah. That has to be done in the UI at the moment. Yep.

A

It makes a lot of sense.

A

Yep, there's nothing so the question was basically: if you pray, if you're, protecting or requiring a status or you have a protected branch, and you want to make sure that your tool that isn't a fully built or baked integration to github, can you still use all those things? And so sir, is essentially yes, you know once you set those once you set those parameters and requirements on the github side, the entire system has to listen to them. There's it's!

A

It's not so much that a third-party tool is respecting those changes were enforcing, and so, if you're, using it nope it's Incans or something like to do the work. It'll it'll have no choice but to respect the rules that are in place on the github side it they may not respond clearly as to why something failed. If they're trying to take an action and we're returning an error and- and maybe they don't aren't giving you that error in return, because it's a newer feature at github, but yes, it'll it'll all still continue to be protected.

A

A

Sure so the question was: to what extent is the github web view a client to the github API? Essentially, none the web view is almost entirely the rails application using you know and sort of just normal work. We do use pjax to a per click, so it's not actually reloading. The entire view is reloading a subset of the view, but we don't use the API to render the UI at all to my knowledge, but definitely not in any major way.

A

That's all completely separate, so the api's are primarily for either the either came from our own interest in building them because we needed them internally or our customers or integrators, but they're definitely focused primarily for the automation side and not for rendering our UI's yeah. They probably only what question if there is one okay awesome. So if you have any more questions, I really invite you to also you can just go to github.com, slash contact or email support at github com.

A

It's there a really awesome group that is very technical and ultimately usually it comes back to the engineers anyway. So if you have any more questions check that out, but otherwise thank you very much.

A