 Good to go. Okay We'll continue with the rest of the tutorial After having a couple of beers, so it will be more entertaining now sure So to go back we were talking about the github integration that we have an easy build to Automate the workflow of contributing back There's some stuff under the covers. There's this check github option That we found out the hard way that we really need to make sure that people have things configured correctly that the github Token is in place that get Python is there That you actually have a fork to push to that the pushing works with the token you give it and so on So based on the checks it does here It will tell you what is supported so from PR you can basically always use You don't need to use a github token for that. It will just pull it from github And as soon as you don't or as long as you don't do like 20 of these in an hour, you'll be fine But at some point github will start complaining at you're doing things too frequently If you have a github token that will not happen for new PR and update PR You need to push rights to your repositories. So then you really need a token. There's no other way Review PR is also read-only so you can get away with not having a token and uploading a test report needs permissions to create gists and To add comments to pull requests. So you need a token for that as well Now ideally if you have things configured correctly, you should get an okay for all of these and then you're good to go to use all these features so The big feature or the new feature that was added is Adding support to the easy build to the eb commands to create new pull requests from the command line. So It basically takes care of the whole workflow for you So you just run this command and at the end you get a pull request with your easy config file Now how the easy config file is named. It doesn't really care because it will rename it and put it in the right place as a part of the Of what it does. So you get one single eb command no git commands no clicking on github. It does everything for you And it tells you what it's doing It will pull in the develop branch from the central repository and then create a branch on top of that So it's showing you here. It has created this branch. It uses the software name and version to come up with a sensible branch name and it uses the date and timestamp to Ensure there's a unique branch name pretty much So if you run this multiple times, you'll get a different branch name every time It renames and relocates the easy config file so it puts it in the right directory gives it the right name Based on the tool chain the version suffix the version and so on so you don't have to do the renaming manually It will target the develop branch of the central repository by default But you can actually use the same thing to target your own repository Like for css for example who has a central repo of their own they could use this as well if they want to it will Auto format or auto generate a title for the pull request which makes sense according to what we Try to get people to do so module class tool chain software name software version And it will mention the pull and the description and it was created a new PR as its self-promotion kind of thing Shows you the overview of what's included in the branch. So here we're adding one single easy config file with all new lines So we're not changing an existing one And it will open the pull request and give you the link to the PR on github so basically all of this and this is very short if you know what you're doing you can One two three four like seven commands you can do it now. It's just one command very short And you don't have to do all of the renaming and checking and make sure everything is okay That helps a lot. No git interaction. No github interaction Another benefit is it doesn't create it creates a local branch on your system But in a temporary directory and as soon as new PR completes It's cleaned up. So you don't even have a local branch to clean up in your clone of the easy comp is that's very useful and Even for people that are used to get and github it saves a lot of time. It's a single command It does everything for you and less stuff to clean up afterwards very similar updating is an existing pull request Works very similarly you give it the number of the existing pull request the easy company file to add And this may be one that exists already. So you just change a couple of things You give it a sensible commit message or in this case you have to give it the commit message yourself It won't make any guesses of what was changed and it will go ahead and do the whole cycle Checking out the right branch that corresponds to the pull request Pulling in that branch locally in a temporary directory copying the easy company file here into the right location and doing the commit That's copying doing the commit with the message you give it and Then pushing that branch into your fork, which basically updates the pull request So again, all of this all of these commands assuming you know what the branch name is and What kind of get magic magic you have to pull is Is now changed to a single command in eb and there's no mess left around afterwards The other way around sort of pulling in from a pull request. This is mainly for testing contributions you give eb from PR the pull request number it will pull in all the easy company files that were touched In that pull request and it will build them by default or you could dry run on them or Check style or check contribute all these things Just to see if things work on your test system and again, this is all done under slash TMP So once this completes everything is blown away. There's no mess left after This is what we use all the time for testing contributions and in combination with from PR. You can do upload test report. So like this Just combine from PR upload test report go back one slide go back, okay One nifty feature here is that you can specify which easy company you want to right Yeah, so one thing you can do here if it pull request has multiple easy conflicts that it's touching so say it's a big PR with 10 easy conflicts As a part of the command then you can specify one of them and then it will only test that one You want to test one specific one with a particular tool chain or you only care about testing one of the easy conflicts You can do it as well You combine it with upload test report it will do the build fully and then at the end It will upload the test report in a gist on github and add a comment in the PR to mention. There's a test report for it So this looks like this this was me testing one of the pull requests and Adam was testing the same PR, but he was using sent to a six so it was failing for him It was working for me and then this is the link to the gist which has the details about what kind of system what kind of easy build configuration and If something fails, yeah, this is a successful one So it just gives you some metadata about the test environment If it fails for the build that fail it will give you a link to the build log So you can click this and figure out what's going wrong. It the build log is partial here to prevent the gist from Being 100 megabytes or something being uploaded. It's only a partial gist only the last part It's usually enough to figure out what the problem was so a maintainer or Say somebody opens a pull request and maintainer sends a test report that failed if the contributor knows what's going on he can figure it out by himself fix it by himself and so that's kind of what we're trying to get to that contributors can figure things out by themselves fix it by Themselves without us telling us telling them how to do it and then one thing that was added later And this is mainly for maintainers, but actually anyone can use it What we're doing here is Comparing a new easy config file with existing easy config files. So say you're adding an easy config file for a new version of CMake that has just been released today You create a new easy config file open a pull request for the new PR a maintainer will use eb review PR with the pull request number and it will just show a diff between Existing easy config files and the new one and it will jump out. This is really a version update Nothing else has changed. So if the test report passes, this should be good to go And this is very hard to do manually because you will have to do the manual visual comparison And it does a diff for you and the detail here is it does a multi diff. So it will Compare one easy config file with multiple others So say you have CMake version 4 and There's existing easy complex for easy complex for version 3 and 2 already It will do a multi diff and so show in the version 4 the version has changed from 3 or 2 to 4 So this gives a nice overview This is not something that github can do because this is an easy build aware diffing So if you don't know what easy config files are you cannot make this by yourself or github cannot do this and Later on we also figured out this is actually also useful for contributors So they can do a preview of a pull request and just run it so you can review on an existing pull request Or preview on an easy config file that will show you a diff view like this. So here with chewing This new easy config file you're adding BAM tools this version The closest one I could find was this older version of BAM tools and the only difference is the version in the Jackson Nothing else is different. Yeah