Developing Projects with GitHub Codespaces

0:11Hi, guys, my name is Trevor Sullivan, and welcome to another CBT Nuggets skill. In this skill, we are going to be continuing our learning about the GitHub platform. In particular, we're going to be focusing on a relatively new feature known as GitHub code spaces. Now, as of right now, code spaces is not available for free users of GitHub, it does require that you either have a GitHub team or an enterprise plan. So if you are building a free open source project on GitHub and this feature isn't currently available to you, then that's probably the reason why is that you'll have to upgrade your organization to a paid plan, so that you can unlock the capability of using this feature.

0:55But before we get too deep into all the details on it, first of all, what exactly is code spaces? Well, as you may know, some years ago, Microsoft actually purchased GitHub. And so GitHub is actually now part of the Microsoft organization. As you also may know, Microsoft is also the developer of a utility that is used very commonly in the software and DevOps industry around how to edit code, and that is known as Microsoft Visual Studio code.

1:26So if you head over to code.VisualStudio.com, this is one of the most popular editors that's currently available. And one of the great things about this editor is that number one, it's cross-platform. It runs on Windows as well as Mac OS, as well as Linux. So you can get a consistent development environment across different operating systems if you're switching between perhaps a Windows 11 workstation like what I'm on right now over to maybe a MacBook Pro that's running Mac OS, you can get that consistent tooling experience across multiple operating systems.

2:03Now, Visual Studio code itself is actually built on a generic framework known as the electronic JS framework. And this is a cross-platform framework that's built in JavaScript, that allows application developers to build cross-platform apps that have that similar look and feel with a singular code base rather than having to have three separate code bases depending on which operating system the user is actually using. Now, because the Visual Studio code editor is built on the electron JS APIs, one of the benefits of it is that because it's JavaScript, it's actually running inside of a browser environment.

2:42It's actually running, I think, on Chromium or some kind of derivative of Chromium essentially. And so what you can actually do is take a Visual Studio code, which is, again, built on electron JS, and you can actually run it in a web browser. In fact, there is a company, I believe it's coder.com, that originally was actually working on kind of a web-based port of Visual Studio code. They were originally working on this project called code server. We're not sure if that's still up to date, it looks like it is.

3:15But this was essentially a project that allowed you to run Microsoft Visual Studio code right here in a web browser. So you can see that they've got a screenshot right here with Firefox running, and they're actually running this Visual Studio code interface right inside of their web browser, instead of having to install Visual Studio code on their actual dev system. Now, this has some obvious benefits. One of those benefits is that if you are running on an unsupported platform that Visual Studio code doesn't really run natively on-- think of like Google Chromebook, for example.

3:48So if you're using a Google Chromebook, and Visual Studio code isn't fully supported on the Chromebook, I think you can probably get it running on there. But if it's not really supported on there, you can actually just fire it up in your web browser and use VS Code in the web browser instead. And so what GitHub has done is because GitHub is part of Microsoft now, they're actually taking Visual Studio code, and they're now hosting it in the web browser. And they've called it the GitHub code spaces feature. Now, you can actually use your Visual Studio code editor natively on your workstation as well.

4:24And then you can actually connect your local VS Code instance up to a code space that is running in GitHub in the Microsoft Azure cloud platform actually behind the scenes. But you do have that choice. So you can run it in the browser or you can run it in the desktop here. And you can see that when you kind of switch this back and forth on their marketing page here, you actually have that consistent user experience. The only real difference is that when you're running it in a web browser, you have the typical address bar. Whereas, when you're running a desktop application, you don't have that browser address bar there.

4:57So that just kind of shows how seamless the experience is between running VS Code as a native desktop app on your dev system locally or running it in your web browser. Now, one of the great things about code spaces in GitHub is that it gives you the flexibility to choose how much system resources, how many system resources you would like to allocate to your development environment that's hosted up in the cloud. So you can choose up to 32 CPU cores, or you can-- and you can also choose up to 64 gigabytes of memory.

5:32So you have a lot of flexibility there in choosing anywhere from two CPU cores all the way up to 32 CPU cores, depending on how much compute capacity you actually need. If you're running some kind of compilation step in your code that takes a really long time, then you might want to bump it up to 32 cores, or if you're just doing some lightweight development testing, DevOps type of stuff and you're just kind of playing around, you might be able to get away with a small two core system. And there's different pricing tiers available, of course, depending on how many system resources you assign to your GitHub code space.

6:06Now, the great thing here as well is that VS Code running in the browser in code spaces also integrates with GitHub itself. So when you create a GitHub repository, you can very easily create a development environment that's directly connected to your GitHub repository with a couple of clicks. So GitHub will take care of cloning, spinning up the virtual machine, it'll get VS Code up and running in your browser, and then it'll clone your GitHub repository onto the virtual machine that's actually running your code space.

6:37And then you'll be able to work and edit your code, and build and test your code inside of that development environments as long as that code space is running. So this is a really neat feature. And as I mentioned before, this is limited to teams if you're on a paid team plan or the enterprise plan. So it's not currently available for free plans, but it wouldn't surprise me if eventually, they make it open source or not open source, but available for open source projects rather. And one of the great things about VS Code as well is that you have this really rich ecosystem of extensions.

7:11I mean, there's extensions for pretty much every language out there, whether you're using Python, or C-sharp, or PowerShell which I very regularly use in VS Code, and lots of other languages and frameworks, just different tooling to help make you a more productive developer. So what we're going to be doing in the rest of this skill is kind of exploring the code spaces feature and some of the customizations that you can apply to it. So we're going to create an empty GitHub repository, we'll just kind of start out from scratch. And then we'll add some files to that repository or maybe just a single file.

7:44Then we'll open it up inside a code spaces and kind of explore what that environment looks like. And then how you can actually customize that environment so every time that you're deploying a code space into your account, you can actually customize the different utilities, the different configuration files that are on that code space environment, so that you have a seamless experience across all the different repositories that you're working on inside of GitHub. So as you can see right here, this is just kind of a table showing the different pricing plans. We've got anywhere from two cores with 4 gigabytes of RAM, that's going to be $0.18 per hour.

8:19So you do pay per hour for this particular service all the way up to $2.88 per hour for a 32 core and 64 gigabyte of RAM system. So we're going to go ahead and jump in to our AWS-- oh, sorry, not AWS, GitHub organization shortly here. And then we'll take a look at the billing for this particular feature and how that works. And then we will actually start taking a look at the feature itself. I hope this has been informative for you and I'd like to thank you for viewing.

0:11Hey guys, and welcome back. So let's go ahead and jump into the GitHub user interface. And we'll actually take a look at how to enable the codespaces feature by setting up Team or Enterprise billing on your organization, as well as how to actually create your very first GitHub codespace. So what we want to do is navigate over to the GitHub user interface. So you can just go to GitHub.com. You should already have an account and be signed in. And one of the features that you can just use inside of GitHub is called an organization.

0:42So if you click on this little plus sign up here in the top right corner, you can actually create a brand new organization. And when you sign up for an organization, you have a few different pricing options. So you can do the basic free tier, where you have public and private repositories. You have limited 2,000 minutes of free private repository minutes for GitHub actions. You also have 500 megabytes of storage for the packages. But one of the things that you don't get here is the ability to use codespaces.

1:15And so you'll want to upgrade your organization to either the Team plan right here or the Enterprise plan. And you're going to pay for those plans based on how many users are actually added to your organization. So if it's just you, you're just an independent developer, perhaps, maybe an independent contractor, and you have your own organization, then you can get away with paying $4 a month for the Team plan. However, you also have to pay for the actual minutes and hours that you're using of codespaces on top of that base plan.

1:46So it's not like codespaces is just unlimited once you pay for $4 a month. You also have to factor in the additional price of the time that you're spinning up that codespace environment, which is actually just running on a virtual machine behind the scenes up in the Microsoft Azure Cloud platform. So once you've created your organization, you should be able to utilize the codespaces feature. I'm just going to go back because I already have an organization created here. So I've got an organization called CBT Trevor.

2:17GitHub.com/cbttrevor. And if I head over to the People tab here, I can see that it's just me and Dan Charbonneau, who's the founder of CBT Nuggets. And we are the two users, or members, of this particular organization. Now if I go over to the Settings section right here and then drill into Billing and Plans, you can see what the currently active plan is on my organization, my CBT Trevor organization. And so right now the current plan for that CBT Trevor organization is the GitHub Team plan.

2:52And you can see right here, it shows me the pricing for the members. So I have two members. And that costs $8 per month, of course, $4 for each user. Now as you scroll down under this Billing section on the organization, you're going to see the usage of some of the different billable features within the platform. So again, the Team or Enterprise feature that you get when you register for that level of a plan in your organization doesn't give you just unlimited access to all the different features.

3:23You still have to pay per minute for things like GitHub actions. If you're using GitHub actions to do CI/CD workflows on your different repositories, then that is going to be extra. They do include 3,000 minutes with the Team plan. But if you exceed that, then you are going to pay additional costs for that. You also have packages. And that's basically just package storage for things like Docker container images or NPM packages or Python packages, that kind of thing. And so you get 10 gigabytes included here.

3:54But again, if you exceed that 10 gigs, you're going to pay for it. Same thing for storage for both GitHub actions and packages. That's billed separately from the actual packages and actions workflows themselves. But as we scroll down here a little bit more, you're going to see codespaces as its own little table here. And you can see that you're actually billed separately for storage and the compute capacity here. So of course, you are going to be consuming storage on your codespace in addition to the virtual CPUs and the memory that you're allocating to your codespace.

4:24And so that's broken down for you right here. And you can see that it even breaks down the different sizes of the compute nodes that are being used to deploy our codespaces. So you can see right now, I've exclusively been using the 2-core, the smallest size, virtual machine here in order to run my codespaces. You can see the fractional hours that are being billed. And you can see exactly what your bill is going to look like. You can also set a spending limit. So if you exceed that spending limit, you can get notified about that. So that you know that, hey, maybe somebody's overprovisioning Github codespace.

4:59Maybe they're using a 32-core virtual machine when they really could just get away with something like maybe a 4-core virtual machine. And so that just gives you some controls over your spending on the platform. But how do we actually create a codespace, right? This is just the high level stuff in terms of enabling the feature on your organization and GitHub. But once you've enabled that feature and you're signed up for Teams or Enterprise plans, how do you actually use the feature? Well, I'm going to come back to my actual organization here.

5:30This is my organization's home page, GitHub.com/cbttrevor. And what we're going to do is start out just by creating an empty repository. So let's just do a new repository here. And I'll call this GitHug-codespaces for now. Feel free to just name your repository whatever you'd like to. And I'm going to make this a public repository for now. And I'm just going to click on Create Repository. Now, this is a completely empty repository. There's no files in here, obviously. We haven't actually created anything.

6:01And so it's giving us the standard home page where it's saying, all right. Here's how you can add some files if you have an existing project locally that you'd like to push up with Git. Or you can just use the GitHub UI here to create new files and things. Now, what you're not going to see, at least as of this recording on this home page here, is an option to open this empty repository inside of codespaces. And this actually confused me at first because I was kind of expecting to see an option here to open the empty Git repository inside of a codespace so I could start adding files, adding folders, and building out my project.

6:35However, that option is not available until you actually create a file here. So I'm just going to create a dummy file. We'll just call it readme.md and just put some random text in there. And then we'll just commit that file. And once we have a file in our Git repository, now you can see that we have this little code dropdown right here. And when you drop that down, normally you just have this option over here, this local tab where you can clone your repository locally on your dev system. So you can choose HTTPS or SSH-based cloning.

7:06Or you can use the GitHub CLI as well, if you are using the CLI tool. But then there's this new tab right here called Codespaces. And this allows you to provision a new codespace. And it'll automatically open up this particular repository in that brand new codespace. Now when you click on Create New Codespace, you're going to be given the option in terms of how many CPU cores and how much memory you would like to allocate to your GitHub codespace. And for most intents and purposes, if you're just doing some pretty lightweight stuff, the 2-core virtual machine is going to be plenty.

7:41So go ahead and just click on Create Codespace. And that is going to pop open a new tab here. And it'll give you this nice little landing page that shows you the status of where your setup is. And basically, what it's doing behind the scenes is it's spinning up a virtual machine. It's spinning up a containerized development environment. And then it's going to take you directly into Visual Studio Code running in your web browser. Now because my browser is currently in the full screen mode-- if I hit F11 in here, I can come out of full screen mode.

8:12Or actually, it's not going to take that. Let me just hit Escape a couple of times here. All right. That's not working for some reason. I think VS Code is actually intercepting my keyboard shortcuts there, which is fine. But you can see as I put my mouse up to the top of the screen here, I'm actually on this GitHub URL right here. And so VS Code, even though it kind of looks like it's running natively on my local system here, it's actually running on a virtual machine somewhere up in the Microsoft Azure Cloud. Now how do I know it's running in the Microsoft Azure Cloud?

8:44Well, if I come over to the documentation for the GitHub codespaces feature and you go to the Overview documentation, it talks to you about what exactly a codespace is. And it kind of breaks down what we talked about before, which is that you can use VS Code desktop locally, or you can run VS Code in your browser, which is what we're doing right here. And that's going to connect the editor over to a virtual machine that, as you can see right here, is running in Azure. And on that virtual machine-- it's a Linux VM.

9:15And it's going to spin up a Docker container. And it's going to clone my source code into that container. It'll pre-install some language runtimes for me. So I'll have things like Python and Ruby available inside of that containerized environment, as well as some common developer tools. So once you've got this environment open here, you can see it's automatically cloned my repository for me. And so that single file that I created just using the GitHub web interface is now available inside of this VS Code environment.

9:47Now, one of the other great features about GitHub codespaces and just VS Code in general is the fact that your settings will actually synchronize with the GitHub service. And so if you were to install extensions from the Extensions Marketplace for Visual Studio Code, those extensions will actually get synchronized to GitHub as set user settings, essentially. And then when you spin up a brand new codespace, because I'm logged in with my GitHub user account, you can see that it's actually doing a synchronization.

10:18And it's actually installing all of the extensions. You can see it's kind of incrementing that number right here. So it's actually going through and installing all of the extensions that GitHub has remembered that I've been using on my local development system when I was also signed in with GitHub. So this is just another level of seamless synchronicity between my local VS Code environment that I'm using on Windows 11, the MacBook Pro that I sometimes use for work as well. I'm also logged in there so I get that synchronization of extensions and VS Code settings there as well.

10:52Plus, when I spin up a GitHub codespace in the cloud, I automatically get that synchronization of extensions and user settings as well. So this looks and feels exactly like my Visual Studio Code editor does running locally on my Windows 11 system. And I didn't have to do any extra work in order to set it up. It just happened because I'm logged in with GitHub. Isn't that great? So now we've got this GitHub codespace environment running. And there's a lot that we could do here. But we're going to take a look at some of the customizations that you can actually apply to your codespaces.

11:26And we'll also take a look at how you can manage your codespaces once they're up and running inside of the GitHub web user interface as well. I hope this has been informative for you, and I'd like to thank you for viewing.

0:11Hey, guys, and welcome back. So in the last video, we deployed our very first GitHub code space and we took a look at how we're running a Visual Studio code in the browser with all of our settings and all of our extensions synchronized, which is a really great feature of this tool. Visual Studio code is a very versatile editor. It's usable for many different languages. You could be a PowerShell developer. You could be a c-sharp developer. You could be a JavaScript developer, Python developer. There's extensions for pretty much everything out there.

0:42Now, one of the things that you can do is actually customize this environment quite a bit because as we saw before in the documentation, we're actually just running our development environment inside of a Docker container somewhere on a virtual machine up in the cloud. And because we're running inside of a container, we can actually customize a lot of the environment that we're working inside of. Now, if you're familiar with Visual Studio code, and you've watched some of my other training here at CBT Nuggets on Visual Studio code, or perhaps on PowerShell automation and things like that, you may have seen me use a feature called Dev containers.

1:17And essentially, what that allows you to do is take your Visual Studio code editor, like what we have right in front of us here, and then, connect it to a containerized environment. And that container could be running locally on your system with Docker desktop, and you could configure it to talk to a remote container as well. But as we saw in the documentation right here in GitHub code spaces, it is basically just connecting that browser-based editor vs Code running in your browser right here. And it's connecting it to that containerized environment, running on a virtual machine.

1:49So what if you wanted to customize that environment, and maybe install some custom software packages as part of the build process, or you want to just apply some kind of customizations to that environment as it is being deployed. Well, there is a really cool capability called devcontainers. And you can actually apply the feature to your GitHub code spaces. And what this allows you to do is to build a custom container image that has your own Dockerfile instructions, or different software packages that you'd like to install or customizations that you'd like to apply to the environment.

2:27Maybe you want to change some configuration files or preload some data onto the file system of that container, as you are working in your projects. But we can use this devcontainer.Json file, to customize the build process for our containerized environment that is running on this Azure virtual machine like what we talked about before. So how do we actually do this? Well, you have this devcontainer.json file, and this sits under your project dot vscodehiddendirectory And so basically, once we create this file, we'll be able to customize some of the different packages that we pre-install on there.

3:08You can also do something known as a post installation hook as well. And so that's going to allow us to run some kind of automation task, after the code spaces environment has been spun up. And you can hook into there and just run arbitrary code to install additional packages after it's been spun up or do any other kind of automation tasks. Maybe you could send an email and just say, hey, my environment is up and running and just send yourself a notification. There's all sorts of types of automation that you could potentially do.

3:38It's actually the dot dev container folder here. Not the dotvs code. The dot vs Code folder is where your settings, dotjson exists, if you have a project specific vs Code settings file. So how do we get this devcontainer.json file, as well as this Dockerfile that we'll use to add in instructions, so that we can customize what software packages are being installed as part of our code spaces deployment process?

4:09Well, it's actually really easy. Because they actually provide an extension that's available inside of the interface here. And if we just hit F1 to pop open the Microsoft Visual Studio code command palette, and we search for code spaces, you can see that we've filtered down the list of vs Code commands here for ones that specifically are coming from the code spaces extension. In fact, if you go over to the extensions, you can either do Control-Shift-X on your keyboard, or click on this icon right here with the blocks.

4:40If we take a look at the installed extensions right here, we should see that there is a GitHub code spaces extension somewhere in here. So let's search for code spaces. And as you can see, here is this GitHub codespaces extension that allows us to get some additional functionality right here in our editor. So if we hit up one again and do codespaces as a search, one of the options that you'll have available here is to add development container configuration files.

5:13And so this will basically generate a stub file for the devcontainer.json, as well as your Dockerfile, that you can then go in and just start customizing, to add in whatever customizations you would like to add to your containerized development environment. Now, before we do that, there is also a bunch of other options here as well for code spaces. So if you need to resize your code space, you can actually do a change machine type option right there. And then, you can change the resources that are provisioned for it.

5:44There's also a common command that you're going to get familiar with too, which is to rebuild the container-- rebuild that devcontainer that's running up on that virtual machine. And any time that you're making changes to your Dockerfile or your devcontainers.json file, or any of the post installation hooks scripts that you're going to be using. You'll be using this rebuild container command fairly often to re-initialize your entire containerized environment, and make sure that all of the changes that you've made to your customization files are actually working properly.

6:19Also, if anything goes wrong during the provisioning of your devcontainer after you've made those customizations to the Dockerfile or to the devcontainers.json file, there is an option to view the creation log right here. And the creation log is just buried somewhere on the file system. It's under slash workspaces.codespaces, which is a hidden directory. And you have to drill down there to find it. But you can actually just hit F1, and then search for code spaces creation log. You can just do a partial search here, and open up that creation log.

6:50And it'll actually open up that log file for you, and show you where things have failed if anything does fail throughout that build process. And you can just do a Control-F and search through here, if there's a specific script that you're executing in your customizations that is failing. So let's go ahead and do some basic customizations here. So I'm going to hit F1, and then, we'll do codespaces, and I'm going to choose the added development container configuration files. And again, what that's going to do, is it's going to generate the option-- the configuration files for us.

7:25And typically, what I like to do, they have these templates here. So you can base it your devcontainer off of an Alpine Linux, lightweight distribution. You could do it based off of a c-sharp environment, or a Debian Linux environment. I generally like to stick with something a little bit more generic. I don't want to pre-install the dot net environment or pre-install Golang. Oftentimes, I'm going to be working with a specific version, and sometimes these types of templates can get out of date very quickly. And if you're looking for the latest version of a runtime, sometimes it's better to just start with a base Debian build, or my personal preference would be to start with a base Ubuntu build.

8:03So I'm going to choose this Ubuntu template right down here. And then once I choose Ubuntu, Linux, it's going to say, hey, which release of Ubuntu do you want to use? Do you want to use vocal phosa, which is the latest LTS or long term support release, which is 20.04. We've also got bionic Beaver down here as well, which is 18.4. And, then I think hirsute is the 21.04 release. I'd have to double check on that. But that's I believe the latest non LTS release. That's a little bit more cutting edge.

8:35Oftentimes, I like to stick with the LTS releases, so I'll just choose vocal phosa here. And then, after you choose the version of Ubuntu Linux that you want to utilize, it'll then ask you if there's any features that you want to install. Now, this is, I did some research on this is actually a relatively new feature within the devcontainer.json file in the vs Code documentation. But what it allows you to do is to pre-install certain common tools. So if you need the PowerShell runtime, you can check that off. If you need an SSH server, so that you can access into the container for maintenance purposes or logging or monitoring purposes.

9:12You can enable an SSH server if you're using things like terraform in tflint to deploy terraform templates, then you can install that as well. Now, I often work with PowerShell. So I'm just going to go ahead and choose PowerShell for now, and click OK. And just select the latest version of PowerShell when prompted here. And after you have chosen all those options, it'll go ahead and stub out these configuration files. So at this point, we've got these this devcontainer folder in our project here. It's actually added that to our Git repository.

9:45So as you can see, we have two pending changes here, two new files that are currently untracked. And we can commit those into our source control repository alongside our other application source code here. But essentially, the devcontainer.json file is what vs Code is interpreting. It's basically saying, all right, these are the parameters that I'm going to use to set up my container based development environment. And if you scroll down just a little bit here, you see this feature's option right here. So this is that new preview option or I don't, I'm not sure if it's beta or preview.

10:17But it's not fully release ready yet. But this is where you can install some pre-defined features inside of your containerized environment. And then remember earlier, I was talking about how there's a post installation-- or post setup hook. So that is actually right here. It's commented out by default, but you can simply uncomment that. And the devcontainers.Json file has the option to run a post create command. So if there's some kind of script file that you want to execute after the devcontainer has been fully initialized then you can plug that in right here.

10:49And that's a handy option for any additional customizations that you don't want to build in directly to your Dockerfile. And then, right here, we, of course, have the Dockerfile itself. And it's very simple. It's basically just going to define an input argument, which is the variant or the addition of the operating system that we want to use. So the default value is hirsute. But when we run the devcontainer.json, it's actually going to be passing and it's going to override that default value with focal fossa instead since we chose that during the generation of these stub files.

11:25But then back here in the Dockerfile, we have just an example run command here in our Dockerfile. So if we uncomment that, we can now take advantage of the ability to install some additional packages. So I think one of the packages that you might want to commonly used is like tmux. And z sure enough, if I try to run tmux down here in the terminal, you can actually see that it's just not available by default in the GitHub code spaces container. So one of the things I could do, is just come into this run command, that it kind of stubbed out for me here.

11:56And where it has this little placeholder, your package list here. I could actually just add in tmux. And if I save that, you'll be able to rebuild this containerized environment, and then tmux will automatically be available inside of this environment. So as we talked about before. If we had F1, to search for rebuild there's the code spaces rebuild container option right here and it's going to pop up this morning saying that this is going to recreate your code space, and it will preserve the unsaved the uncommitted changes.

12:30So those in configuration files that we just generated will be maintained, so we can continue to work on them. But it's going to go ahead and basically just wipe out that container, and rebuild it using the parameters that we specified in our Custom Dev container and Docker files. So once this containerised environment comes back up and running, We should have tmux available, because we have now specified that we want that installed in our Dockerfile.

13:00Let's just give this a quick minute to finish running, and it'll spit us back into VS Code shortly here. All right, so as you can see, we are back in Microsoft Visual Studio code here. And you can see that we are in our containerized environment here. And I've actually lost the customisations that I had before when I was signed in with my GitHub user account because I have actually overridden the default configuration with these devcontainer files here. So one of the things that I'm expecting to see that's different in this containerized environment is that tmux should now be available inside of this custom container.

13:37In fact, this little welcome message right down here specifically tells me you are on a custom image defined in your devcontainer.json files. So GitHub Codespaces knows that we have overridden the default container configuration, the default Codespaces container, with our own customized container that's based on Ubuntu Linux. And then we have some additional customizations that we're running down here. Of course, you could add a lot of other Dockerfile instructions here to install other packages or download packages from other package repositories, besides apt.

14:11You don't have to use apt. But if there's like some custom scripts that you want to run to install a third-party utility, you could certainly do that there. But down here in the terminal, I should be able to run tmux now. And sure enough, because I've customized my Dockerfile, I am able to run tmux now. So using the devcontainer.json, as well as the Dockerfile, gives you the powerful capability of customizing your devcontainer to your project's specific needs. Just keep in mind that because these files are part of your repository.

14:44Well, at least they will be once we actually add them and commit them to the repository. But once they are part of your repository, any developer that's going to collaborate on your project using GitHub code spaces is automatically going to inherit these settings because they're part of the repository. However, git code spaces actually does provide another facility to allow you to provide specific customizations that only apply to your GitHub user account, not to the entire project and we'll look at that in a separate video.

15:15I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Hey guys, and welcome back. In the last video, we took a look at how to utilize the devcontainer functionality in order to customize the software and configurations that are being used to provision our devcontainer that's running on that Azure virtual machine behind the scenes in the GitHub Codespaces feature.

0:31Now, one of the other things that you can do to customize your development environment is to make user specific changes. So these devcontainer.json and Docker file files are going to apply to the entire project. So anybody who is using this project over here, of course, once we've committed these, let's just say adding devcontainer files really quick, and then we'll just do a sync changes that push those up to the repository. Now, if we come over to the repository, we should see that folder show up.

1:02There's devcontainer. And then we've got our two files in there. So if any other developer that's collaborating on this particular project comes along and spins up a Codespace, they're automatically going to get these customizations inside of their Codespace as well, because the GitHub Codespaces feature will simply pick up automatically on the fact that these files exist and apply them to the dev environment. If there are customizations that only you, individually, on your team need to apply to the GitHub Codespaces environment, you can actually do that with a separate feature known as GitHub dotfiles instead.

1:41And that's actually going to be something that you apply at your specific User Configuration on GitHub. So if we come up to our user account right up here and go down to Settings, and we drill down into Codespaces, which is a little ways down right here, you'll see that we have this option right here. It's a little checkbox that says automatically install dotfiles. And then we have this option to choose a repository that contains our dotfiles.

2:11So how does this work? Well, if we drill over into the GitHub documentation here for GitHub Codespaces in particular, and then drill into customizing your Codespace and then choose Personalize Your Codespace, there are a couple of options that you have here. First of all, we talked about that Settings Sync earlier. So this allows you to share your Visual Studio code extensions and your configuration files. It sets your font, and your theme, your preferred color theme, and all those types of advanced options. That's one benefit of using the VS Code environment in Codespaces.

2:44But the other one is this dotfiles feature here. If I just click to jump down to dotfiles right here, let's do a little bit of reading about this. So dotfiles are special files that start with a period. They're just basically hidden files on the file system that control configurations. But if we drill down a little bit further right here, when you create a new Codespace, this is really important, so when you provision a new Codespace, not if you have an existing Codespace and just open it up, so it has to be either rebuilt or created completely from scratch, then GitHub will actually clone the selected repository that you selected on this screen right here in your user profile.

3:26And this only applies to your user account, not to anybody else that's collaborating on your project. And so what it's going to say is it's going to clone that repository locally that you select in your user settings there to the Codespace environment. And then once it clones that locally, it's going to look for some special file names to perform some additional configuration steps. So the first file name it's going to look for is something called install.sh. So if that file exists and it has a shebang that points to shell in the environment, like PowerShell, or BASH, or SH, or something like that.

4:06And it is set to be executable, so, of course, you have to have the executable bit set on that file, if that file exists, then the GitHub Codespaces environment will actually try to trigger that script and run whatever commands are inside of that script. And there are some other file names that it will try as well. So if install.sh doesn't exist, it'll look for one with install with no file extension. It'll look for a bootstrap.sh, bootstrap with no file extension, and so on and so forth. So you have a couple of different options here.

4:38So it's going to attempt to automatically run these scripts when you spin up your Codespace. Now, before we actually try to do that, one of the things we'll need to do is actually to terminate our Codespace. So I'll come over back to my GitHub user interface and go to Your Codespaces. And you can only have a maximum of 10 Codespaces running at a time. Right now, I only have two right here. But I'm just going to go ahead and just choose the option to delete this Codespace. And that's going to kind of reset it back to square one.

5:08And now, once we add in this customization, we'll be able to spin it back up. And it'll apply that customization. So let's go ahead and try this out. One of the things that we'll need to do is actually create a repository under our personal user account. So I'll go to My Repositories, not My Organization Repositories, just me individually, My Repositories. And I'll create a new repository just called github codespaces customizations.

5:39Again, you can name this whatever you want to. And you also want to make sure that it is set to public. In the documentation, they refer to ensuring that it is public, in the troubleshooting documentation. And then we'll hit Create Repository. Now in this repository here, we're going to go ahead and clone this on our local system. So I'm going to fire up a shell here. And then I'm going to go ahead and just go into my Git directory here. And I'll just do a simple git clone on this directory here.

6:11And I'm going to go ahead and do cd github codespaces customizations. And as you can see, it's just empty, right? So I'm going to do vim install.sh. And I'm going to go ahead and just do a shebang here. And we'll say usr/bin/env bash. And then let's say that we wanted to do something like installing a PowerShell module. So what we could do is invoke PowerShell, because PowerShell is going to be installed as a result of that devcontainer.json file that we had earlier.

6:43If you recall, it's under the Features, the kind of well-known features section there. But let's say that we wanted to install a module for PowerShell as part of the initialization process. So I could do a bash script that actually calls PowerShell and say PowerShell -command. And then we'll do Install-Module -name. I'm going to install the pode web server. It's just a web server module that allows you to create web servers in PowerShell, and then specify the -force parameter here. So I'll go ahead and do a colon wq to save that.

7:17And the other thing I need to do is do a git update index. And just to make sure that this has the execute bit set, we're going to do git update index, chmod equals plus x. And then we're going to do that on install.sh. And of course, I need to do this --add. There we go. And then we'll do git status. So we've got this new file to add. So we'll do git add install.sh, git commit.

7:49And we'll say adding install script. And then we'll do a git push. So we've basically created a hook, a script that will run after the initialization of our GitHub Codespace environment that's going to install an extra PowerShell module for us. But that's only going to happen for us. It won't happen to any other collaborators, because their GitHub account will not be configured to actually use that setting. So let me just refresh my repository here.

8:20And sure enough, there is our install.sh script. And it's got that code in there. It's basically just going to run a bash script, which is going to call PowerShell. And now I'm going to come over to my Codespaces settings. And under the Codespaces section here, I'm going to go ahead and make sure that this box is checked. And then I'm going to select the repository that I just created. So let's search for github codespaces customizations, that's the repository that I just created with my personal customizations on it.

8:53And now it has automatically saved that setting. So in order to test this out, again, we need to make sure that Codespace is terminated, which we already did. And so now we'll go back to our organization. I'll go back to Organizations go to CBT Trevor, and then we'll open up this github-codespaces repository that we created. And will go ahead and create a new Codespace here, with two cores. And just give that a moment to spin up. So it's going to apply the devcontainer.json configuration.

9:26It's going to use the Docker file to build that containerised environment, which includes tmux that we customized in the last video. And then it's also going to apply our user specific customizations that we created as well, which should kick off that bash script, which then calls PowerShell, and installs a PowerShell module from the PowerShell gallery over at powershell.com. And that's just an example. You could replace that PowerShell call with any other command that you want to or any other series of commands that you would like to. But that's just a really simple example to show that I can trigger a script that basically just run some additional customizations after the fact.

10:04So once this VS Code environment opens back up, we should have all of our customizations. Of course, we get that message saying that, hey, you are on a custom image that you have configured with your devcontainer.json file here. And of course, I should be able to run tmux here. And yep, sure enough, it looks like tmux is there. It looks like it's still installing some extensions here. It's kind of re-initializing everything from scratch, since we rebuilt this Codespace from complete scratch. It has to go through and install all the different extensions that I have.

10:38But it looks like tmux is working OK. And I should also have PowerShell installed as well. So there's PowerShell. And now, to validate that the install script, the hook that we just created, is actually working correctly from our personalized settings that we applied right over here under the GitHub settings, under Codespaces, we reference this github-codespaces-customizations repository that has our install.sh script.

11:10So what we should be able to do is run git-modlue -listavailable. And if I hit Enter here, let me just clear the screen really quick, as you can see, the pode module is actually installed. So that's basically just confirming that we have successfully triggered that post setup hook script. And it executed it successfully. Now, I did run into some issues when I was originally testing this. You do want to make sure that you are ch modding that file in the actual Git index itself, not just on the local file system.

11:47But you want to make sure that you're actually updating the Git index. And make sure that the execute bit is set on that particular file. Otherwise, it will fail to trigger it correctly. Also another issue that you could potentially run into is the type of line endings that are used. So if you're using Windows based line endings instead of Unix based line endings, that can also cause that post-installation hook to fail to execute as well. So just be aware of a couple of those potential issues that you could come across.

12:17But sure enough, it did actually execute. Now, just to troubleshoot this, if something did go wrong, we can take a look at the creation log, as we looked at before, if we hit F1 in the editor here, and look at the creation log, that's one of the Codespaces commands that you can run. Or you can actually just open it up from the file system if you know where to look. So by default, you're going to be stuck in this code, GitHub Codespaces-- this is actually your repository folder. But if you go up one level and then do an ls-ll, do ls-lga, and that'll actually reveal the hidden folder here called dot codespaces.

12:59And this is kind of a meta folder that the GitHub Codespaces feature uses. And if we drill into that directory and do an ls, eventually, let me do ls-lga, drill into dot persistedshare, cd dot persistedshare. And then we'll do ls-lga once more. And as you can see, the creation log actually exists in that persisted share hidden directory, which is under the Codespaces hidden directory under the slash workspaces root directory.

13:33So if you need to look at that creation log, it does exist under there. Or you can just use that F1 shortcut to go find it. Also, if you take a look at this dotfiles directory right here, you can actually just cd into that. So we'll do cd dotfiles, do ls-lga. And look what's there. That is the install.sh script. So if I just cat installsh, that is actually the install script that we created when we created that custom repository right over here with our customizations in it, just under my user account.

14:08That's a repository that doesn't exist under my CBT Trevor Organization. It's just customizations for me personally within any of my Codespaces. So as you can see, that's a really nice hook to be able to hook in and customize your Codespaces. You can install software packages, install modules for your framework of choice. You can apply configuration files. You can pretty much do whatever you want to. I hope this has been informative for you. And I'd like to thank you for viewing.

0:11Hey, guys. And welcome back. There's one other feature I wanted to cover in the GitHub codespaces service, and that is the ability to create encrypted secrets for your codespaces. Now, there might be things like API keys or other types of secrets that are specific to your user account. So when you're logged in to GitHub and you create a GitHub codespace, you only want those secrets to be available to you personally not anybody who has access to your shared GitHub repository.

0:42So that's something we can actually configure as an environment variable for that GitHub codespace. And then any time that you personally spin up a codespace, you'll be able to see those secrets as environment variables, whereas other users that are collaborating on your GitHub repository will not be able to see them. So just really quickly here, if we take a look at our organization, which is CBT Trevor, then we have this organization repository called GitHub Codespaces, this is kind of our shared working environment with the rest of our colleagues, because this is where our application code would go as we're building out some kind of application.

1:20So on this organization repository, if there's any common API secrets that we need to share with the rest of the team, we would probably configure those at the repository level. So on this repository if we drill over to Settings and then scroll down and go to Secrets, you can see that we have the ability to set repository level secrets right here. And I've actually used this feature a fair amount in some of my other training on GitHub actions workflows so that you can use secret values for things like AWS Cloud secret access keys that you want to use inside of a GitHub workflow-- GitHub Actions workflow, rather.

1:59You can store those in the repository level secrets and then reference those inside of the GitHub actions workflows. However, if there are API keys, as we talked about, that are specific to you individually that are not to be shared with the rest of the team right here, then you can configure those on your individual codespaces settings. And that is another GitHub profile-level, not a repository- but a profile-level setting, similar to the dot file setting that we looked at in the last video.

2:29So if we come up to the top-right corner here, again, for our user account and then we drill down under Settings right here, well these are our personal account settings for our GitHub account. And if we scroll back down to Codespaces here, this is the same screen where we configured that dot file's beta feature, where we basically said, here's my personal repository that has a install script that I want to execute any time that I deploy a new codespace. Now, right below that, we have this option to create codespace secrets.

3:03And as you can see, it describes what those are. Secrets are environment variables. So it'll be exposed to the codespace as an environment variable. And we can use that from Bash. We can use it from Python. We can use it from any process that's running in that codespace. They're encrypted by GitHub, and they're only exposed to codespaces that you personally create for yourself. So if we create a new secret here-- and I'll call this Trevor Secret Key. And I'll set the value to whoever likes to eat bacon and any kind of meats.

3:40And then we'll go ahead and just add that secret here. Of course, we have to also select the repositories that we want to expose it to. So let's do our cbttrevor/github-codespaces. So let me do a search for codespaces, so cbttrevor/github-codespaces. So that will be the repository that we're working on with other team members. But we want this secret for just us to be exposed to that environment. So we'll say Add Secret. And now we need to go ahead and either rebuild our codespace environment, or we need to restart it.

4:19So as the documentation says right here for codespaces encrypted secrets, once you have created a secret, it will only be available when you either create a new codespace or when you restart the codespace. So if you have a current codespace, you'll need to stop the codespace and then resume it in order to use that environment variable. So if I was to come over to my codespace environment right here-- I want to close this old one. And if I do a, let's say, dollar-- what is it-- Get-ChildItem on the ENV drive-- that's a PowerShell thing.

4:54If I look for that Trevor Secret Key, I don't see that environment variable here. So here's term, term program. I don't see any other T environment variables. So let's go ahead and restart our codespace. So we'll say stop codespace. We'll say codespaces stop current codespace. And just access that from the command palette. And then once that has been stopped, we'll go ahead and just get it restarted. And then we should have access to that environment variable.

5:25So we'll go ahead and just click on that button to restart it. Plus, you can always go over to your codespaces right here. And you can open it in your browser right here. That'll be under your User Settings up here. And then just go to Your Codespaces. That'll list out any codespaces that you've provisioned across different organizations. And then you can choose to either open it in the browser, or you actually have this option here to open it locally in VS Code as well. But let's come back over here, and we'll give it a second to just spin up here.

5:56And this time it's going to be a little bit faster because we're not actually repositioning it. All we did is we stopped it and then restarted it. So it doesn't have to go back and install all the extensions. All those extensions should still be installed from the previous execution. Sure enough, you can see my 52 extensions there. So that part's fine. That's not going to take any extra time. But as we can see right here in the terminal-- let me see, terminal. Where's my terminal? Show me my terminal-- debug terminal?

6:26No. What happened to it? I think it's still starting up. So here's my terminal. And then we'll fire up PowerShell. And then we'll do Get-ChildItem on the ENV drive, PS drive. And sure enough, now you can see that we've got this new environment variable Trevor Secret Key. And it has my super secure API key right there. So that's basically how you can set up API secrets that are specific to just your user account.

6:57You can use those on codespaces, again, as long as you have allowed them to be used on those particular repositories. So if you try to go to a different repository and use that secret and it doesn't show up, then you want to come back to your Settings, go to Your Codespaces, take a look at this secret right here and make sure that any repositories that you want to use it on are actually listed right here. Otherwise that secret simply won't be available for codespaces for those particular repositories.

7:28I hope this has been informative for you, and I'd like to thank you for viewing.