 Okay, it's Jeff Chalon again. In this screencast, we're going to look quickly at how to get things set up so that you can submit assignments using Test 161. So the first thing I want to point out here is that the Test 161 is designed so that you get a very accurate idea of how you're going to do on an assignment locally. So you should not repeatedly be submitting assignments for remote grading. You should be iterating locally using Test 161 locally to see how you're going to do. And then when you're happy with the score, submit to the submission system and see how you do there. That's pretty important to make sure that the load is distributed among all your machines rather than concentrated on our backend server. When assignments or deadlines are approaching, you may see there be backups in terms of the grading. We'll see how that goes. But really, again, you're supposed to be able to do as much of this locally as possible. The other thing that you'll notice is that when you submit things for backend testing, the output is actually different because we're configuring your kernel differently. A lot of the messages you normally see during testing are disabled. That allows the test to run faster. But that's also because remote testing is not designed to produce diagnostic output. Finally, if you're missing tests that are required to evaluate your kernel, if we didn't give you tests, it's because we want you to write them as part of the assignment. Please do that rather than repeatedly submitting your assignments for grading. This couple of things you need to do to get ready to submit. You need to configure Test 161 locally so that it knows who you are. You need to configure the backend so the backend knows how to get a copy of your repository. Let's talk about how to do the second thing first. Part of this is now going to be done through the Test 161 backend. Here's our Test 161 server, test161.opsclass.org. There's a link now from the main opsclass.page that'll take you over to the Test 161 page as well. Here I am. This is the view that you'll see. We're still working out some bugs here with how some of the things look. That'll change over time. Up here, there's a login button. We're going to use the same credentials that I used for the GitLab instance and for discourse and that's going to lock me in. I'm logged in. What I see here is pretty much an out of date and not perfectly formatted version of the instructions that we have up on the main opsclass page, which is what I would use for now. Right here is something I need to do right when I get started. This is a profile. This has two things. The submit token is something that I'm going to use in my test161.com file to tell the test server who I am and make sure that this is done securely. Your Test 161, this submit token is secret. Please don't share it with other people other than your partner. Your partner will need to have this in order to submit on your path, but you should not give it to anybody else. If you're worried that it's been compromised, you can always regenerate it using this button right here. It's going to ask you, once you regenerate a token, the old token is not good anymore, so please only regenerate a token. If you need to, you'll have to change your configuration file and notify your partner. So I'm not going to do that. Okay. Probably one of the trickier parts of getting this to work is that the back end needs access to your Git repository. You are going to submit, essentially submit a Git commit ID, which is what identifies the code that you want us to test. The Test 161 site is going to be strict about not testing public Git repositories. The repository that you use for the code in this class has to be private. If we can detect that it's public, we will not test it. If you're in a course that's using this, that may be grounds for failing the class. You are responsible for making sure that that repository is private. Again, if we can detect that it's public, the staff will be notified, and that may be grounds for failing the course. So please make sure that your repository is secure. But we still need to be able to access your repository during testing, so how are we going to do that? What we're going to do is we're going to allow you to generate your own public key. The private key is going to be stored on our server, and this public key is something that you'll use to configure a repository to allow us to access it. I'll show you how to do that using GitLab. There's a process using GitHub that I'll walk you through a little bit too that's pretty similar. Other Git repositories probably have ways of doing this as well, but I'm going to show you how to do it on GitLab and then I'll get on GitHub. Okay. So the first thing I need to do is to generate a public key. You see that I haven't generated one yet. Hit this button, type in my email address, hit regenerate, and boom. Okay. So now here is the public key that matches the private key that Test 161 is going to try to use to clone my repository. Now it's important that this is a per user. It's not on a per user basis. So if your partner creates this, they, and if they're submitting, they will also need their own key, and they will need to configure the repository to use these, both of these keys. So now I have a unique key. Now let's imagine that I'm using our local GitLab instance. This is mine. Obviously there's some things in here that you guys might find interesting, but we're not going to poke around too much. Instead, what I'm going to do is configure it so that it can clone the base sources. This is a kind of a clone of the base sources that we maintain on GitHub for you guys to use. This has some sort of private changes and other things. Okay. So on GitLab, the way you do this is you go navigate to the repository that you want to use. And what we're going to do is we're going to add what's called a deploy key. A deploy key is not associated with my account. It's associated with the repository. And it allows me to provide Test 161 the ability to clone this repository, but not push to it. And that's pretty important. So please do not add this key to your user profile on GitHub, to your user profile on our GitLab instance. You don't want to give this key all that power. All you want to do is give this key the ability to clone this one single repository. So how I do that on GitLab is, again, I go to the repository. Here's our base sources. I click settings. And here is this thing over here called deploy keys. I'm going to click on deploy keys. You can see that there's already some deploy keys that we're using to test other things. I'm going to hit new deploy key. I call this test161.opsclass.org or whatever you want to call it. The name is really kind of relevant. I paste in the key that was just generated and hit create. So now you can see that there's a deploy key enabled for this project. And what that means is that Test 161, the back end, can now clone my Git repository. It can't push to it, but it can pull from it. And that's what I need in order to submit. OK, now let me kind of show you how to do that on GitHub. Just as an example, I won't actually do this, but let's go here and let's imagine, now these repositories are public, so they would be flagged by the Test 161 server. So I'm not going to actually do this, but I'll kind of show you how to go through the process. GitHub is its own settings menu over here, and it also has deploy keys. And I can add a deploy key here. Pretty much the same process. Give it a name, paste the key value in. GitHub actually allows you to add write access, which I would not do. And then you're done. The other thing that we found out about GitHub was that GitHub actually enforces the fact that all deploy keys have to be unique. So if you try to add the same deploy key to two different repositories, GitHub will not like that. And so the idea here is that this deploy key should be used only on the private GitHub repository where you store the OS 161 sources that you want to submit. That's the only place you should use it. If you try to add it twice, if you're given to your partner and they try to add it to a different repository, it's not going to work. So now we're done. I mean, that's what we needed to do. I've got my repository here on our private GitHub instance configured so that I can pull from it. And then the last thing I need to do is adjust my configuration so that I can submit. And so if you remember, in the beginning, we ran test 161 run and it, you know, printed off a configuration file. I didn't have one that I was using that. So let's do this again where we recreate our test 161.com file. I'm going to put in, just write this quickly, path to my root and the test 161. And now we're going to use these values. So now the server is something that you can just leave alone. That's our test 161 backend server. The repository I need to give it the SSH link to the repository. Sorry, the get that link to the repository. If I was using GitHub, that would be you can get access to that. This is the wrong repo. You can get access to that by clicking here and then you get the get at GitHub link. We're not going to use HTTPS links. We're only going to use to get that links or something at the clone over SSH links that I lost is to use the key. And then I need to set up my user. So I'm just going to do this on my behalf. I enter my own email address and then here's where I need that token that I just generated right here. So I'm going to take my submit token paste that in here. If you have a partner, you need to put their email address. Most of you have partners, their email address and their private token here. So contact your partner out of band to get their private token. I don't have a partner. So I'm just going to put this in here like this and this is done. So now I can go back to my and make sure that things are still working or not working in this case because I'm about to get to zero out of 50. Okay, so this is it now. If you switch partners, that would be a great time to regenerate your submit token and make sure that your partner can't submit things on your behalf. So now we've seen how to set things up to submit and the next screencast will actually submit an assignment. See how it goes.