1:27 Introduction & Guests

1:27 Hello and welcome to today's episode of Rawkode live. I'm your host, Rawkode. Today, we're gonna be taking a look at Gitpod. Before we do that, I just wanna take a moment to say thank you to my employer, Equinix Metal. They are a bare metal cloud, and they provide the time and the resources that allows me to invest in a show and produce great cloud native learning materials so we can all learn together. If you wanna check out Equinix metal, please visit metal.equinix.com and use the code Rawkode dash live. This will give you $50 of credit. That $50 can get you roughly

2:00 one hundred hours of compute on our smallest instance. So check it out, have some fun, and let me know how you get on. Now today to look at Gitpod, I am joined by two they're great team members, Christian and Sven. Hello. How are you both? Hi, David. Great. Hey. Good. Awesome. Thank you. Would you just like to just take a moment to first introduce yourselves and then we'll talk about what Gitpod is and how it can help us? Chris, do you wanna start? Yeah. I can I can have a go? So my name is Chris. I'm the chief

2:20 Introductions

2:33 architect at Gitpod. And my role is to make sure we stay sort of technically coherent and, you know, decide on how we build this or guide the discussion on how we build this thing and make sure the team stays aligned on that from the technical perspective. Yeah. I'm Sven. I'm one of the cofounders and CEO of Gitpod. And, yeah, my passion is like, I'm I'm an engineer also, but I really, like, look into the product stuff and yeah. It's in in entirety. Awesome. So should we start by just saying, you know, what is Gitpod and what what problem does

3:11 What is Gitpod & Problem Solved

3:16 it aim to solve? Yeah. Of course. So Gitpod is dev environments in the cloud. Basically, our plan is always be ready to code. So what we wanna make sure is that developers stop wasting their time on manually setting up local machines, you know, with databases, compilers, stuff like that before they can start coding. We it's pretty simple. Like, we apply lessons learned from infrastructure's code and continuous integration. So what you do is you describe your development environment, which is not only the IDE, but all the tools you need. You describe that in code and have that part of your Git repository,

3:40 How Gitpod Works: Dev Environments as Code

3:59 so it's versioned. And with that, when someone pushes a change, we can always, you know, recreate entire dev environments that are fully initialized and ready to call. We do that in the cloud. So when a developer comes by, wants to start a dev environment on a certain branch, it takes a couple of seconds in order to get dive into being creative and working in code. Yes. I think it's this kind of tooling is is becoming more and more important. You know, I think before we went live, I talked about my my aspirations of being able to survive on a

4:24 Benefits & Use Cases

4:35 Chromebook as my day to day machine. And one of the challenges there is is having the toolings to work on projects. But even more importantly than that, you know, I think making the path easier for open source contributors to pick up a new project and a language that they're maybe not all that comfortable with with tooling that they're not all that comfortable with and have a tool that get pod where they can click button and have a working environment for for making their first contribution, I think, is is definitely important. So can we if we understand what what's the process then

5:03 Whats the process

5:06 with Gitpod, you know, is this something that we expect the maintainers of the projects to put together themselves when they're making it available in open source? I mean, yes. The the configuration for that needs to be engineered by the team. So the team decides on what what is the perfect dev environment for all of us. You know, there are means that you add your personal touches on on top with key bindings and stuff like that. You can you can do that for sure. But at the core, we decide as a team, like, okay. Let's we use, you know, this compiler and that

5:46 version, and we have this one time, and we use that code generator, and we use that database, or we have even 10 different databases in our unit test we wanna test against. And so that's all stuff you do as a team. It doesn't matter whether you do that in open source or in some commercial project. You of course, in open source, you have even more external collaborators, contributors for whom you wanna make, you know, pay for path, make it super easy to contribute, spin up a dev environment. But even in commercial projects, I mean, I've

6:20 I've been working as a consultant for ten, fifteen years now. I haven't seen a project, like a commercial real world project where I was up to speed in in a couple of minutes. Usually, it takes two days until we can do do some work. Yeah. Yeah. I remember an organization I worked at a few years ago where they forced all the developers to use an ID that was baked inside of a vagrant image. And they all had to use the same settings and the same color scheme and the same key bindings and all of that. And

6:51 IDE Flexibility & Options (VS Code, Theia, BYO)

6:51 I understand the intent there, but definitely not the ideal solution. Whereas something like that seems much more flexible. Now, I think the most important question I'm gonna ask you today is, does it have them key bindings? If if there is a Versus code extension for Vim, then yes. Right. Nice. So that's okay. So it loads Versus code extension. That's awesome. Let's pull up my my screen. So this is the Gitpod homepage. If you're following along at home or wanna check this out on the replay, is getpod.io. So does is Gitpod. Does it just use the Versus

7:08 Gitpod vs Code

7:30 Code extensions or is that built on top of Versus Code itself? Both. It's a bit yeah. Like, the IDE part of that is really not, like, the critical thing we wanna get across. Like, what we really wanna achieve is that developers can bundle up the tools they love and they wanna use they would use locally. They bundle them up in this recipe that Gitpod can execute and provide you in a cloud. So you should be able to use the IDE you love. Right? When we started out, we saw, okay. Like, Versus Code is a great IDE. We

8:04 we love it, and it seems to have a market share that is significant and, you know, and increasing. So we looked at Versus Code and and checked whether we can, you know, somehow move it into the cloud, also talk with them actually. And so at that point in time, they just came from the cloud. There was an online version of Versus Code many years ago. They moved it to the desktop, built Versus Code, and at at that point and they said, no. We are not interested in changing the architecture. We wanna focus on desktop entirely. So what

8:38 we did is we saw that there are cool components like the Monaco editor and they, you know, develop the language of protocols. So we took those ingredients and created, an online ID called Feya. We moved that to the Eclipse Foundation because that's really not the point. We wanna make and get this good part is to build yet another IDE. We wanted to source this dev environment stuff and give developers the IDE they love. But fast forward two years, Microsoft has changed its, you know, architectural decisions. So they made Versus changed the architecture in Versus Code so that it runs now nicely

9:16 in browsers as well. And, you know, probably have heard of GitHub code spaces. And so they did that in the open source version. So since last week, you can choose and get part whether you wanna use Thea or Versus Code as a browser front end. In both IDEs, you can install any Versus Code extension. Alright. Nice. To dwell on the point that really the IDE that you're using is is something that you can choose and not something that we prescribe, There is a feature that's currently in private beta even where it can bring your own

9:51 IDE as as a docker image, and that could be anything, you know, Jupyter Labs, Jupyter Notebook. If you sign client, it could be just a terminal with Emacs behind the scenes. So, really, the the point is we want to automate the the dev environment as a whole, and the IDE is one part of it. And we want to be orthogonal to the IDEs that you might want to use. Alright. So yeah. That's that's really important. I don't think I fully understand that. I understood that as we were coming into this. You know, I was thinking,

10:24 it's an ID that runs in the cloud and provides us other stuff. But really, there's just so much more to it than that. So alright. So from this homepage, I can see a try now button just sitting there attempting me to click it. So I'm just gonna go ahead and do that. Let's see. So so I can just take any repository and add it to the end of that URL and it's gonna open it up for me? That's correct. So I already opened a few in advance. For the audience, what I have here is a

10:31 Starting a Workspace (Demo)

10:58 project called Git series. So good. I wrote it twice. Once in Rust, once in Go. I'll get answer that another day of why I did that. But it is a project that can scan, get repositories, export metrics from it a time series format. I also have another project. I seem to do a lot with Git now. Don't realize this. But this one's called Git sync. It's a GitOps operator written in Rust. And I have an Equinix metal terraform provider due to be renamed any day now. Currently, it still says packet. And I'm just gonna add this to the start.

11:32 Does it a protocol matter? Should I remove that? It doesn't matter. But for Gitpod, actually, I'm not sure if it's back. No. Let's let's continue. I will show you with the other repo. Alright. So now it's just saying log in and launch workspace. So I'll authorize this. Alright. So do you wanna give me a little bit of insight into what's actually happening here? Yeah. So what's happening in the background or what just happened was that Gitpod understood from the URL that you provided or that you that was the suffix, basically. It understood which repository you wanted to open,

11:56 Workspace Initialization Process

12:15 which Git hosting provider you wanted it to open from. And it, as you then saw, talked to to GitLab, signed you in so that you got access to to that repository. And then behind the scenes, it started a a Kubernetes pod with the IDE in with user land and with a default sort of image that we call workspace full that has a lot of tools installed already and started the IDE for you. Alright. I can see that it's downloaded all the Go modules. It's asking me if I wanna set up the project or just never.

12:49 Handling Dependencies & Dockerfile (Initial Go Demo)

12:57 What do you think would be a good first step here? Will we click never or will we click setup? Should I just start breaking We can set it up. Yeah. We can set up your project. It's it should be relatively easy. Okay. So the first thing you need to do is, like, you know, you you could use and just code along here in in this IDE now, but it's it's not you know, it's there's no real kind of automation in there. So it's just, you know, it's a checkout of of the context you've you've started with, which is the default branch here.

13:33 With the Gitpod YAML, what you can do is you can tell Gitpod what kind of, for instance, base docker image you wanna have in your like, when you, you know, when you in in your tools, you wanna maybe install additional tools like a database or stuff like that. And also what kind of tasks should be executed. So if you click create Gitpod YAML, it analyzes your project a bit. And and if you double click the Gitpod YAML tab in the middle, you can make it full screen. And you see what it analyze. It's pretty simple. It

14:10 says, like, okay. When you ever someone starts this project, we have two things we wanna execute one after the other. First, we wanna run GoGecko build and go test. And then afterwards, we wanna run, actually, the one. So that's just the super simple gold standard thing. What is important here is there is this two different life cycles. It's you know, there's init and there's command. The point is that init can be executed asynchronously. So when you check-in this, you can install a webhook on your GitLab repository, and then we'll Gitpod will run through this interface

14:53 whenever someone pushes a new branch and you commit to any branches. And it runs through that, and then it takes a snapshot. And then when a a real human being comes along, wants to start coding, you don't have to wait for this. So this is, you very significant for a long running build. Like, if you need to download the the Internet because you have so many dependencies or, you know, do stuff like that, then you don't have to wait for that. You get a fully kind of initialized compiled code generated source code within a couple of seconds.

15:27 Very cool. To to bring the point home how much time that saves, if you do that on on Gitpod IO or the Gitpod IO repository itself, you'll save about twelve minutes by not having to sit there and watch PaintDry code download and compile. Right? Yeah. I could see I could see a lot of benefits to the push definitely. And I guess in a really weird way, if I were, you know assuming it wasn't 2020 and I'm out on a, you know, holiday period, Christmas night out with my workmates and I need to fix something on my phone, I could I'm assuming

16:05 I could just pop that open and never have to leave restaurant. So I like that idea. And not that I've ever had to fix any production outage from a restaurant before. That wasn't definitely wasn't painful. Okay. We actually had a a question just as we were chatting there. So let's pop that up. So Ofer is asking, will we show how to use or utilize Docker compose and have that run containers when we start the workspace? Yeah. We'll definitely try and get around to that. Okay. Now should I update this docker configuration? I'm assuming that it's just a docker file

16:42 that is used to provide the tooling environment for this workspace. Okay. That that's correct. So there there are two ways you can provide the user land for your workspace. One is you can list in an already built image, and we're gonna pull that and use that. Or you can provide your own Dockerfile, check that in in your repository, and then whenever you make a change to that and open a new workspace on it, Gitpod will build that for you. Alright. I'm gonna click it. Okay. So you provide some defaults, VNC. Yeah. It you know, some not everything runs

17:24 in the browser yet. So if you need to do something that doesn't run-in the browser, you need, I know, need to run UI tests, for example, then this image comes in handy. And it starts a VNC server on a frame buffer and then gives you web VNC view to it. Alright. Cool. I'll just click custom. And I just it wants me to provide an image with a name. So what is the Gitpod workspace fill that it's suggesting here? That's the default one. We have a like, you know, that's the one we are running currently on. Like, if you don't provide anything,

18:05 then we use the workspace full and it it you know, the name is accurate. It it has everything you probably might wanna have. So it's it's, you know, it's yeah. Batteries included very big image that is, fast to pull because it's it sits on every note already, pre pull. But it's probably not what you really, you know, in a professional context, you wanna, you know, maybe say, okay. I really need this version of Go or I need that. No. And then then you wanna be very specific, so you would start with a hand rolled docker image.

18:48 Okay. I'll just skip this for now then. Okay. Yeah. You can yeah. You can now you could generate a Gitpod Dockerfile, but please just don't don't do that because we don't need that for the simple project. Yeah. Yeah. Yeah. That's that's kinda what I was getting there. So okay. So we can let others know that this project, I'm gonna click update with me because I just, click in the blue button. Alright. You can just close the tab on the right. There's this icon. Yeah. Click on the text. Alright. Let's pop this channel down. Let's see what that's done to my read

19:22 me then. Alright. It wants me to update something and just say, hey. This is It yeah. It added this button, this batch to the top. If you click the preview icon on the top right, yeah, that one that one, you see what it did. Oh, got it. Okay. So you've added a badge then allows other people to pop us open instead of Gitpod. Right. Excellent. That was all pretty painless. So I guess and now I can start making changes to this application and just develop it as I normally would. Like, not really much should change with my normal developer workflow.

20:01 Is that right? Correct. Yeah. So if you open a a Go file, for example, I saw earlier the Go get looks like it didn't go through because of some native dependency. But by and large, you know, it it will run Go, please, behind the scenes. It's the Versus Code Go extension that we all know. So it should we should feel right at home. Oh, yeah. It seems to have failed here because lib get was not available. So this is just a debian box. So in theory, I should just be able to install that. Right? Let's see if I got sudo.

20:45 So this brings us to a good point that is currently in in feature preview. So we have sort of this you could consider the better feature channel like you have with many other projects that you can enable in the settings, and this would give you sudo. And then you could just do exactly what you were trying to do. If you want, we can go ahead and and just enable that. This would also, though, be a good use case for the stocker file that we were just about to create because this is something that everyone in your team will need. Everyone

21:17 who opens this project will need that library. So there's a good chance you'll want that installed in the user land for everyone. Right? You don't want everyone after they open the workspace to have to go and do app get install Yeah. Lib get. Alright. So what do you want me to do first? I think it it'd be best now probably if we enable the the feature preview just to show that off, and it really helps sort of getting that Docker file ready. To do that, if you on the upper right corner on your avatar, and then click on open workspaces.

21:47 Enabling Feature Preview (Sudo Support)

21:57 And then again in the upper right corner in the avatar, hit settings. And then there you see the feature preview at the bottom. Oh, yep. There we go. If you tick that, that's it. And so the next workspace any next workspace that you'll start will have support for sudo, apt get, etcetera. The the code that you just ticked is exactly what Sven alluded to earlier where we're really not opinionated about the IDE that you want to use. And there is some some code support in there. It's still a bit rough around the edges, I would say. So

22:37 I wouldn't recommend that that we take it on now. Okay. Just, you know, some things like extensions being preinstalled are are still in the works. About to land the PR is actually on the repository. So let let's continue with that. Okay. And so that just saves automatically. Right? There's not anything I have to do here. Okay. So I can just close this. Mhmm. And then we come back to here. Do I need to reload this workspace? You would have to stop and start it again. And to do that, again, the upper right corner or the command

23:02 Stopping, Starting & Persistence

23:08 palette in in Versus Code. So command shift p and then stop workspace, and that will it's important to note that this is only something you have to do, you know, by now because we're changing these settings. Once these settings are enabled, this is not something that that you'll have to do again. Okay. So we're just waiting for this to stop. I'm assuming my start button's gonna come back, and we just go straight back in. Correct. Nice. And it's backing up now, like, the file system of your workspace, you, you know, get that state back again.

23:48 But when I've earlier explained that we have this prebuilt feature and and, you know, it it allows you to skip the waiting, The real reason behind that, you can start the workspace now. Yeah. I just thought this was quite interesting here. Uh-huh. It's kind of all those changes that I started to make are still gonna be available when I come back, which is really cool. Yes. It also tells you what what did change, and you see that here in the tab. So if you have a bunch of Gitpod tabs closed, you can see what state they were

23:56 Ephemeral Workspaces & Workflow Philosophy

24:18 in, and it will also show that in in the dashboard. So, you know, if you have a list of in the workspace list so if you have a list of workspaces, you can then still see what was in in case you left something accidentally, for example. Okay. What's explicit we are so explicit about these changes thing and so on because we know we wanna emphasize or allow people to treat dev environments as ephemeral or disposable. So we would always, you know, start fresh. You usually don't do that, like, stopping and starting workspaces again unless you are working on

24:31 Start fresh

24:52 the long running feature branch. So and so when you go to your workspaces list, this is just reading your history. Like and there should be little reason to restart these workspaces because you can always rely on the automation and get the freshly prepared ones on the latest, you know, state of your branches when you go to GitLab and start from there. So that's that's the workflow. You always start fresh and even in parallel, and then you just close your tab, and Gitpod will take care of, you know or even garbage collect. Like, we are stopping the workspace.

25:26 And then eventually, after fourteen days of inactivity, it will be garbage collected so you don't have to clean up after you. Yeah. Cool. To to illustrate that point further on a good day, I'll have anywhere between 20 to 25 workspaces. Right? I'll have I'll have two to three running in parallel like this and that PR that I'm trying to review, this feature that I'm working on while I'm waiting for build somewhere else. And the only time I really ever restart one is when I come back from lunch, and that's about it. I think the okay. So I've got two questions.

25:58 Browser Extension for Easy Access

26:01 First one, ask me if I want to install a Chrome extension. I am curious what what does that bring to the environment? It adds a button like that says Gitpod to all your to every GitHub and Bitbucket org and GitLab repository, even pull request, merge request issues. So you can start from any you know, you see on the Internet, you see code. There is a Gitpod button next to it. You click it, and then you you can code on that. Awesome. Good. That light led me onto my what my next question was gonna be there because because you just said, you know,

26:34 Pull Request Review Workflow Introduction

26:36 about pull requests. I mean, if I have a pull request for the repository and, you know, it's not always great to look at it and that they get help views, and I can open that specific bar, that branch, that revision, and say that we Gitpod and actually walk through the changes in a more familiar environment. Right? K. Yeah. It even noticed that you are starting on a if you start from a full request, the IDE doesn't open like this. It opens with the changes on the left, and then you can skip both through that, and you

27:06 see, you know, these editors. And you can even comment in line in the editor. Like, you know, you don't have to go back to GitHub in order to do your code review. You just do it from the IDE. You can even approve or, you know, comment, reject, whatnot. Okay. I I mean, we're definitely gonna have try that to fill in because I'm into a help some Helm charts repositories. I run the influx DB Helm charts, and it gets a lot of pull requests. There's a lot of work, and anything that can simplify that for me, like, I'm immediately sold.

27:38 So hopefully, we can try that. Let's let's do something rudimentary with this go set up and then maybe we can look at one of those pull requests and see how that works. Alright. So we enable the feature preview because we want the ability to do sudo. So I'm just gonna do sudo l s and that now worked. But you also suggested that this lib get two is not something that we want to have everybody installed manually. So we probably want to add our own get pod dot docker file. Is that correct? Mhmm. Yes. Okay. What's the flow that that I found works

28:11 Dockerfile

28:14 is, you know, first, you gotta find out the exact name of the package that you want to install. So now we could in in this terminal, we could do up get updates, up install Just to make sure we're picking the right package and that our up go get runs through, and then we we take that and we package that into the into the Docker file. Okay. So we will need lib get to dash dev. Is there a helper for creating this Docker file or should I just go ahead and do, like, new file here? There is. You can also open the view

28:51 on the right with the Gitpod icon again and update Docker configuration once more. Use default. And, yes, generated Gitpod deck of the k. So now okay. Yeah. So that name is completely wherever I want it to be. This is just what's set by default. Okay. Cool. Because I I I'm very fussy over fails on my repository, so it states that that's an option. Alright. Let's get this working then. So now I ran an app update from this terminal because I'm just used to container images, really stripping all that stuff out. Is that the same for Gitpod or does

29:33 that step unnecessary here? I think you need to do that. Yep. Be wary beware that this later will run headless. Right? So if you do apt install or apt get install, you need to make sure that it's not asking exactly. It's not asking for confirmation or anything like that. Yeah. I'll I'll just set this to front end. This environment variable will later be available in your workspace too. So if you set it here like this, then in your workspace, it will be set like that as well. Exactly. Okay. With a with a cleaner. And this does not run as rules, so

29:41 Install

30:19 it better put sudo before. K. Oh, provided there. There we go. Sudo. So now that I've added the Dockerfile and made some changes, is there anything I need to do to switch to this new image? Yes. You need to get that into your remote Git repository. So you need to create a branch and push it there because it's Git first. You know, Gitpod yeah. You you open new dev environments from from Git. So if you have it on a branch or on your phone, whatever, and you start different moments from there, Gitpod understands. Okay. That's,

31:10 you know, that's the configuration I need to to choose. I'm assuming I can just use these tools here to Yep. To do that. Okay. So I can say, add it both configuration. You can also create a branch in the status bar where it says master. If you click on that, then it will ask you if you want to create a new branch. K. Then You need to stage. Yeah. This plus. And then the small tick up top. Yep. That's it. And to push, you can use the command palette. You can use Gitpush in your terminal.

31:26 Create a branch

32:05 And that's it. Okay. So I guess I should pull this back up from here. And it was good series go. Right. So should I just create a merge request? Yeah. You don't have to in order to change it. You can to test it, you can also just go to the branch, load it on the features. You mean from Yeah. You you select that one, and then you see the web ID button. I wanna show you, like, use the drop down and choose Gitpod because Gitpod has a native integration, GitLab, so you don't need to prefix this stuff.

32:57 Okay. Now we can use it. We have just had it enabled once. And this is opening the branch. Okay. Correct. Do see the the context URL on top? Yes. Right. Oh, I broke it. So I'll start with the default image and fix that, I guess. You can go to the to the other workspace and fix the problem and then just force push again. But I I couldn't stop the problem. Oh, yeah. I forgot I think it was signed. So I I just tried to run it as I as I command. Mhmm. So okay. So I'll just amend that commit so

33:36 Stage a commit

33:40 we can stage this. Use you can use the amend button. And then Right. Just that one. Perfect. Okay. And you guys still gotta push. So if you again, you can just use the command palette for that. First push. Oh, yeah. Yeah. The fourth push. Yeah. K. So let's just pop back to here and try that again. It's attempting to and build our custom image, which should hopefully this time work. Yeah. It looks better. Okay. And you were saying this only does this once. So anyone else that now comes to this project, they're just gonna get the built version

34:41 of this image and not have to wait. Right? Correct. Until you make a change to to the image of or to the file, of course. Okay. And what we should see the reason that we did this was because let get caused our goal build to fail earlier. So now when this pops open, we should see our terminal set in there whether a built binary, I'm assuming. Okay. Correct. Yeah. And it should execute the things we listed in the tasks in the Gitpodium now because we pushed the Gitpodium as well. Excellent. Oh, no. I think this is just a good thing

35:29 now. This is not anything that we've done. Yeah. I'm not sure about that error message. Maybe there's some version. The version in the Ubuntu package doesn't match up with what we're expecting here. Yeah. You're correct. We installed web 28 because that was available in Ubuntu, and this uses version 30. So let's just see if it's fixed. If not, we can move to another project. I'm gonna have to get a specific version for that, I think. Let's see. Leases twenty eight eight six twenty eight. And then download. See if that makes it a little bit happier.

36:38 And go build. I'm gonna need some. I broke it. Oh, well. Not important. Oh, it's just added that back in, actually. This is why I tried to avoid using Libgit whenever possible. There is a good good go native Git implementation as well. Oh, really? Okay. I don't know if I really wanna keep trying to fix this. Yeah. So the the the v 30 import seems to be across a few files. And I just don't think that's important. So let's pop open something else then. Let's do the Rust project. Feeling brave. Right? Think let's see. Gitpod I o slash

37:34 Starting a Rust Project (Second Demo)

37:53 and slash whatever we wanna call that. Get menu environment. So you mentioned earlier that Gitpod tries to kind of does it do language detection? It tries to work at what sensible default makes sense for each repositories. Is that correct? Maybe. Yes and no. So it it does that in in some very simple cases like the ones that we've seen for for Go, but it's not very yeah. Okay. Elaborate. Oh, because this is using the workspace fill image, is that just mean as prebaked with binaries and languages, like support for popular languages? Mhmm. Because I do have access to Rust

38:43 c here. Yep. I do have PHP, L. I mean, I'm having quite a lot of languages here. So Node, Python, Go. Oh, alright. So let's click setup project again. We'll create the Gitpod. It has detected oh, yeah. It's a bit small. What's that? So that detect that was rust. It knows that I wanted to a cargo build, a cargo watch. I don't think we're gonna need that. I'll update the read me with the cool button again. Not sure what happened there. K. Let's skip it. Is there a read me? I'm a bit of a cowboy developer, so it's

39:06 Cargo build

39:36 very likely that there's not for sure. Alright. And then we'll just push that and start. Okay. So I can do a cargo. And the crates is gonna compel that one. Maybe gonna work. You know, I don't even know. I've picked another repository that uses libkat again. So who knows what's gonna happen? Maybe it's happier. So can we come in? Sorry, Nico. Sorry. One thing that, you know, might seem minor but actually really works in in the daily life of a developer is that exactly because your workspace is now running in the cloud, download speeds are just so much faster.

40:19 Like, in downloading libraries, dependencies, docker images, you name it, you know, it just flies off. It's Yeah. Definitely. The download speeds were pretty quick. Although, unfortunately, I don't think you can speed up the Rust Belt times, which are notoriously bad. So We can eliminate them by, you know, running them in a prebuilt. Like, all everything we are waiting here for would be something we could do as a cleansing. Well, that was pretty quick, and I've I've actually I think this is they're just working. Target. Oh, no. This is just a library, so there's no target. So, again, that worked.

41:01 Now this is I I would just call it as normal now. Right? Like, I would pop open my file. Oh, that's my commented stuff. There we go. And I have everything that I need to work. Awesome. And are there any features from this ID interface that you wanna cover before we we carry on? Is there anything here that is maybe slightly different to the way that I would work normally? The thing is jumping out to me. I'll just throw it there as a suggestion. I I see no open ports. Mhmm. Yeah. So what we're doing there is if you have

41:15 Port Forwarding & Exposing Services

41:36 some service running in your workspace that listens on a port, Gitpod will detect that and then will make it available outside of the workspace. You can open that in in your browser. And by default, they are private, meaning that only you can access it because, you know, you're logged in to Gitpod. But you can also make them public, and then anyone can just access that. So you could, I don't know, provide an endpoint to some other service, or you can share that with a colleague to download something, stuff like that. Okay. So does that mean

42:06 Sharing your workspace

42:11 random stupid oh, I don't oh, yeah. That'll work. If I just install NGINX on this, I can just close that and someone can just browse to engine x? That's correct. Oh, it detected it as well. Alright. Open a preview. I have an engine x page. Make public. That's pretty cool. Nice. So obviously, if I was that's again me, I'm on farm today. I've picked two really bad examples for showing off a feature. But if I was working on a a website or a React application, been able to just run that dev server, expose support like I have done for NGINX

43:00 here, and give that link to people. They can just come in and see exactly where I am, what's working, what's not working, etcetera. Is there like, if I want if you wanted to, like, pair with me on an issue, is there, like, any support for that where we'd be able to modify the code at the same time? So there is some there are two ways of of sharing your workspace. One is you can share the the workspace as it's running. So at the moment, this just means you're giving someone else access to, basically, to your machine,

43:10 Collaboration Features (Sharing, Pair Programming)

43:37 right, like your workspace. But the example is like you're handing your laptop to someone else, kinda like that. The you share some of the the terminals at that point, and we're still working on adding some, like, Google Doc style life editing that you also share editors. And the other mode of sharing is where you can share a snapshot. So say you have a problem right now or you have something that you would like to demonstrate, then you can create a snapshot of your current state, which produces a link that, then you can put into an issue, share on Slack, something

44:11 like that. And then someone else can go and open that link and get a snapshot based on your current state, but it's gonna get a workspace, excuse me, based on your current state, but it's gonna be a separate workspace. Right? It's like a copy that was branched off it and where you took the snapshot. Okay. Cool. So you are working on Google Docsys style code editing stuff. Nice. We do. Yeah. In theory, you could also use the live share extension from Microsoft. It's just that their license doesn't allow it to install it in Azure in in non visual studio products at the

44:36 Running a web server

44:47 moment. So but we are working on a, you know, on on some collaborative editing extensions for the. Very, very cool. Okay. You shared a command with me. Yeah. This is a really quick way to get a get a web server up and running. So, you know, short of installing NGINX, if you just need a web server that serves a file, you you push that in, and it's gonna spin up a web server for you. Alright. Okay. Nice thing is that that works independently of any kind of, you know, whatever whatever you have installed. Behind the scenes, it

45:22 just downloads a gold binary and runs it. So this is gonna work. And I could never remember the Python line or, you know, the PHP line, and it's just gonna start with stuff. It's really handy for debugging. Yeah. That's a really cool tip, actually. I wasn't familiar with that. So alright. Let's we got another question from over. Working on my computer, I can save a file today and it will be available forever. And Gitpod, how long can I keep files that I saved in ID but have not yet been pushed to the repository? There yeah. I mentioned before we have an automatic

45:36 How long can I keep a file

45:58 garbage collection thing. So by default, if you don't restart your workspace for two weeks, then it it gets deleted. There is one another week where we we could restore the state. But you can pin your workspace. If you wanna have a long living workspace, so you wanna do the same everyone does locally, like you have this, you know, stateful stuff that you massage over your lifespan, then you can do that in Gitpod as well. You can have one workspace pin it, and then it will never be coverage collected. You can restart that, menu the sync, and so on. It's just, you know,

46:38 we are trying to educate people to get rid of that because it is, you know, the the root cause for configuration drift and and very different states in in environments where, you know, you you cannot really call this dev environments as code if you do not really execute the automation all the time. If you do it once and then you massage it from there, it you know, it's it's it's nice for starters, basically, but but then you you do the same stuff you do locally. Yeah. You're just trying to encourage some best practices for people across the board. Right.

47:22 So if I just close this tab, that workspace is gonna continue to run until I go back to it, until it gets garbage collected. But, you know, is there a way that is should I, like, click stop? Like, our So the workspace is gonna run for another two minutes after you close the tab just in case you accidentally closed it and, you know, command shift t, still there. So it does that. You can also explicitly stop it in the file menu in the command palette Okay. Whichever suits your your workflow. Alright. Yeah. And if if forget about it,

48:00 you know, you get distracted, you go to lunch or whatever. The time out is thirty minutes by default, and there are there are ways also to extend it to three hours in in some of the professional plans. But yeah. I think thirty minutes is is is pretty pretty okay. Then in that case, you just come back and you see, oh, it stopped. You started again. You touch a new new look. Alright. Thank you. I'm just gonna play with this now, see if I can find some extensions. I changed this theme. It doesn't seem to be returning.

48:36 Finding extensions

48:39 Yeah. So we are like, the IDEs and Gitpod, they do not point to the Microsoft marketplace. But, again, that is not okay due to the terms. So in order to make the all these open source, these code extensions are available to everyone and also competition projects like like Gitpod and so on. We created the open BSX marketplace. We moved that to the Eclipse Foundation so that it's really on a vendor neutral place, you know, that. And then now this this is kind of getting adoption. So Versus Codium, like, that is the real open source version

49:19 of Versus Code. They are also pointing to OpenVSX now by default. Gitpod, like, all CIR IDEs would point to open the as expected fold. Yeah. And if there's something missing, you can go to the project and, you know, create an issue and and just, you know, make sure it it gets added. Okay. I'm just gonna keep clicking stuff. Oh, there we go. That's actually the one I use locally sometimes anyway. Very cool. Alright. Let's close this down. I really wanna check out the pull request stuff that we talked about earlier. So let's pull that up.

49:57 Pull Request Review Workflow Demonstration

50:05 And well, I need the extension then to do this or assuming No. Hub won't have the same native thing like GitLab had. No. You just use your port request. Okay. Alright. Let's just pick this one. So can see. Code spacing. So did I just get pod at the start? Correct. Yeah. Correct. If you have the the browser extension installed, then you're also gonna see a a button in the upper right corner. Alright. Cool. And this is gonna give me a slightly different view that we've we've seen with the last two projects because it's detecting that I

50:51 was at a pull request from this. Correct. Okay. What have I got? Oh, so it's just straight into the the death mode. I can click through the files. Double click. Double click and then And then you can also use the cursor keys in order to navigate through all the changes one by one. And you can add columns if in case you have questions or k. So, I mean, I've already approved this, but if I wanted to add a comment, what's Mhmm. I would say that You hover over the the change line on the right hand

51:49 side, like and you see this conversation symbol. You click on it. Ah, okay. So this is pretty it feels pretty similar to what I would actually do from the GAP site. I can have the single comment or actually start a review and and build up all those comments. And Right. And you would also see all existing comments here. There is a comments view even. And also on the right hand side, you see the GitHub symbol. There you see more details on the full request. And so you see conversations. If you click on conversations, you would see, you know, existing

52:23 conversations. To the files and see them in the in the different contexts. Very, very cool. This is a much better experience for working with a pull request than working from the GitHub UI. I like it. It also means you can try it out directly because you have a full blown dev environment. You know, this isn't just yet another view on on the PR itself, but you have a terminal. And if your project is Gitpodified, if you have a configuration, everything is, you know, set up and ready to go, you can run tests, debug even, and then try it out proper.

52:36 Working with pull requests

53:01 The workspace fill doesn't come with helm, I don't think, with control. But I could provide them with my own image because this is a help charge repository. So the tooling that I need is kinda specific. Alright. Is there any integration with GitHub actions? Like, would I be able to see if the if the last run was successful or if it failed or what failed? Or is that something I would have to jump back over to GitHub to investigate? Yeah. There's nothing special about that, probably, an extension around that that you could install. But, yeah, we do not use GitHub actions,

53:41 so I don't really know. Okay. I mean, I guess that's the other cool thing is that this has access to the open BSX marketplace. So if there's an extension out there that already has GitHub action status support, then it's just gonna magically work anyway. So that's pretty cool. Thanks. Do I have the ability to approve the pull request from here? Yes. Usually, revenue changes. Yeah. There we go. And then And then I can just review this. I can just approve it again. Oh, I think permissions. We need a new scope. Interesting. Yeah. I don't think I

54:32 can't remember if I authenticated with GitHub or not. Maybe I did. You can review that in the upper right corner on your avatar. There is a point called access control. The second that one. They can see what permissions your current token has on. Okay. Yeah. I write public repos is, I guess, the thing you would need. That's annoying. Let me grab that. Yeah. So by default, we try and, you know, grab the least privileges for your account possible. And then, yeah, as you need more, usually, we'll ask for it. Alright. That worked. I've now approved it again.

55:42 And I can be And you can jump yeah. You you can even merge or go back to GitHub by clicking on the the issue number on top right. In fact, I can merge it from here where it's asking me if I wanna do a squash or a rebase, or I can click the issue number, come over here, and just go ahead and do that. So there. Nice. That's very convenient. I can see just how useful that kind of is there. With regards to the the setups, how would one contribute to Gitpod to understand that this was a

56:16 Contributing Configurations & Standard Images

56:21 Helm chart repo? Like, what would be the process for that? Like, if I was, hey. I work at Helm charts a lot. I wanna make Gitpod work better by default for these kind of repositories. Is there as there some way for me to contribute that towards a project? The the way you would solve that is for your project. You know, we can't we we like, Gitpod is really designed to be non opinionated about what kind of projects to support. So we want you we wanna allow developers to just say, okay. I I need this tool, that tool, that CLI tool,

56:36 Adding Gitpod to your project

56:54 that extensions, and so on, and please bundle that up for me. So you would put that into your Docker the Docker file as we did previously with with Git library. We would add few control and helm as part of your Docker file. If you say, this is a really common case, and I know there is this, you know, detection mechanism and get what I wanna contribute to that. Of course, the Gitpod is open source. So if you go to GitHub, Gitpod IO Gitpod, which is a repository, and you can, you know, look whether there's an feature request around this already or you

57:33 file one and then set indicate you wanna contribute to us, and we we can see whether that fits the scope of the project and and where to best to make to the contribution. Yeah. I guess what I was more I guess what I was curious about was, like, you know, if I come here, for instance, and I add the Gitpod.YAML Mhmm. You know, when we added that custom Dockerfile, really all we did I can't remember the exact syntax, so, you know but roughly, we said, hey. There's this image which is built from this file. Can I

58:09 just tell it to use say, published some Gitpod images called Helm and tell people, hey? If you if you want to add a Gitpod YAML to your project, then use this image and it'll come with all the tools that you need for Helm, you know, rather than all these other developers also adding their own Gitpod Dockerfile, you know, providing maybe some semantics around that, I guess. So Yeah. Of course, you can do that. Like and and also and we have this, you know, docker images repository where we maintain those that were proposed when you, you know, earlier used to set up

58:44 with it. There were a list of files or docker images that were proposed. Right? Workspace full, but also the one with VNC or different databases and so on. Those are maintained in an open source repository, and there are some some more, you know, there are for very typical setups, then it might make sense. Yeah. Okay. Perfect. So let me ask another question then. Do you use Gitpod to build Gitpod? Sure. We and we have done so for for quite a long time at this point. Two years easy. Okay. Does your Gitpod have a Docker compose

59:26 Docker Compose Integration Demo

59:29 file or should I throw one together in this project? No. Okay. Let's throw one together in here. Okay. And then alright. So we'll do that just so we had a question about how that would work. So I show that and then we can open get pod and get pod and then I think that's a pretty good overview of of what get pod is and how it makes developers lives better. So let's see. Sure. I can remember how to build one of these things. So let's just do engine x. Assume we're gonna run that, and I can just add the ports.

1:00:07 And I'll add one more. I see I can remember how to do it, then I would get it wrong. Okay. Let's add something with PHP. Put it in CLI image. So this is a really simple and contrived over a compose file. I mean, that's just a little bit bigger. Let's close this down just now. We do have access to Docker Compose and the workspace fill image. Correct. So the first thing you would wanna do is actually start the the Docker daemon. And this is still a preview feature, so, you know, we're still flushing out the UX,

1:00:47 and it was important to give people access to this as soon as possible. For now, to start the Docker daemon, you type sudo docker minus up, and that will do the rest. And that just started the the docker daemon now. Okay. How do I open a new channel? There we go. And would I just work with my standard tooling normally? So I would just run a docker compose up here. Yep. Yeah. We don't it doesn't matter if that container exits. It's not really important. It's pretty quick at downloading the images, benefits of cloud. And my connection's not that fast, so that's

1:01:37 pretty cool. You said that the the start of the episode, this is just running as a Kubernetes pod? That is correct. Yes. So the Gitpod as a whole so now it did the Docker compose up and recognized that there's something running. And and the status bar where it says port, if you click that again, then you'll find a button where you can exactly open browser. There you go. So, I mean, that's just that's just my native dev workflow. Like, you know, that could be you know, I've added PHP, but this could be MySQL. It could be any it could be Postgres,

1:02:24 MongoDB. My application would just be configured to speak on local host like in any other other setup. There's nothing particularly it it doesn't change anything, which I like. Like, all my native tooling is still the exact same, only I'm using someone else's computer, which which is a nice benefit. Which you don't have to set up. Which you don't have to set up. Exactly. Yeah. Alright. It was just too easy. I'm very impressed. I I I like it. It's just, you know, I don't feel like I've been there's not been any friction. There's not been frustrating. I've just clicked I mean and the

1:03:02 fact that I can just use Gitpod.io as a prefix on any repository and pull request is is very very cool. You've definitely put a lot of effort into the kind of user experience here and I think that changed too. So great job. Alright. Let's do our if there's any more questions or anything that you wanna understand about Gitpod, feel free to drop them in the comments. We'll open up the Gitpod repository now. And I'm assuming it's just gonna work as well, but still be fun to do. So do you host the Gitpod source code on

1:03:15 Opening Gitpod Source in Gitpod

1:03:31 GitHub, GitLab, or somewhere else or both? It is GitHub. GitHub. Currently. Alright. Let's pop over. Gitpod.io. Yeah. Right. And we'll add a prefix. So would you say this is the best example of a project configured for Gitpod usage? For ourselves, probably. But for people who are not so involved in it, I guess, it's good. Like, examples are pretty good if they, you know, get out of the way and show off, you know, the thing you really wanna show. So I like, for instance, stuff like these, the pet clinic project or to do this typical to do apps that have this,

1:04:37 you know, conflict. Everyone knows the problem and everyone knows what's going on there, but then you have still, like, this configuration with the database and app servers. And the really good real world configuration is also the GitLab project itself. Like, you know, GitLab or GitLab is using Gitpod for development. And so that configuration is also like, that's a that's a huge project, and there is you know, the configuration is is not very simple. It's pretty involved. Alright. So I'm sorry, Nico. Sorry. Good thing to show here now is the in the terminal in in both terminals,

1:05:20 So we had tasks running in parallel originally. You see this this message, this task ran as part of a workspace prebuild. And what that basically means is that, you know, all the code in this workspace has already been built. Dependencies have been downloaded. You're ready to go. So I'm always quite happy when I see that banana because it basically tells me I don't have to go and get a coffee now. Yeah. It's like that x k c d comic where it's like, it's compiling. No. Sorry. We've done that in advance. Stop slacking off. So two things that jumped out at me with

1:05:56 this repository. One, the theme I installed in the last repository is is now seems to be global for my my set my other experience. So I'm assuming all my keyboard shortcuts and stuff like that are all just gonna transfer between, which is really cool. I also noticed that this opened two terminals say by say, is this something you've configured in the Gitpod YAML or is this yeah. Okay. Let's take a look at it then. Is this a mono repo? Yes. Good. I was gonna ask you a question about mono repos. That's very handy. Alright. Let's drop this down

1:06:34 Gitpod.yml Advanced Configuration Details

1:06:34 and see what we've got in here. So but a prebaked dev environment image hosted on GCR. I go to the workspace location and a checkout location. And there are a lot of ports. The tasks we've not seen the before syntax yet. Is that just like good runs before the edit command itself? Yeah. So the what the before does is it runs before anything else, and it does so independently of the of the life cycle that Sven mentioned earlier. So before will run-in a prebuilt, but it will also run-in not a prebuilt, like, if you start a

1:07:20 regular workspace. Alright. And if you have multiple tasks, you can just add this open mode to tell to run-in a separate thing. And there's a list of Versus code extensions, which you think will make my life easier here. So that's pretty cool too. I don't know if this is I I don't know if the conversations are or whatnot, but, you know, Versus Code has some sort of fail like this. Is there any chance of standardization there that I'd find this once and it works on both, know, Gitpod, the Versus Code, and and intelligent products or whatever like that. Like,

1:07:34 Future Standardization (Dev Container Format)

1:07:54 do you see that being something that happens? I I guess so. Eventually, we see, like, you know, how what is commonly being used. But given that, you know, GitHub and and Microsoft have a lot of reach and the dev container format, and that's the format you are talking about, is pretty nicely designed. So we have an our road map. Yeah. The the plan to eventually support that. It's not, you know, highest on the list, but because also adoption is not really very interesting currently. But I I assume this will change a bit. So maybe q two, q '3 next

1:08:33 year, we'll have some sort of support for this format as well. It's important that, you know, here we have some some more, like, some additional information that we would need in order to do stuff like the preloads and so on because that's not supported by by the format from from this code. But it would be a great start, and it would make it super easy for people to start the Gitpod workspace for repositories that have the dev container format for sure. Awesome. As I mentioned to add, like, I wanted to add one thing to the thing you

1:09:07 User vs. Workspace Extensions Clarification

1:09:10 mentioned before, David, regarding, like, your theme is now on every workspace. This is because you install that as a user. I'm not sure if you remember. It was asked whether you wanna install it on a workspace or a producer, and installing things for user makes a lot of sense. These extensions here sorry. These extensions here are installed for workspaces. That's why it's shared within, you know, the Gitpod demo and then with the with the with the entire team. Yeah. I thought I remember the the pop up. It said, do you want to make us a workspace

1:09:43 extension or user extension? I had to select user because I was don't wanna force my theme on everyone else, I guess, that uses this for j. And is there anything we should show from the Gitpod setup? Like, how does the mono repository stuff work here? Like, you know, I've got maybe a part of it. Let's go. I'm assuming the UI is is TypeScript and React. Like, how does this all work together? Yeah. So the the key challenge that we see is for one that Go Please needs each Go Go module to be its own workspace route.

1:09:53 Debugging and Standard Developer Workflow

1:10:18 So the way we set up the repository is on the components, we basically have the the, you know, the components that make up this project. And they're a mix of TypeScript and Go, And then each Go component is its own Go module. We don't have a root Go module, and they're added as as workspace roots. And that yeah. That's pretty much all there is to it. Alright. Awesome. Is there anything that I should show here? Or is there anything anything that we haven't covered so far about the Gitpod configuration that you think is is important to cover?

1:11:00 I mean, we could briefly show debugging. I mean, know, at the end of the day, it works like you would expect it to work in in your local Versus code as well. But for exam you know, debugging go tests, for example, works just the same way. Yeah. Actually, I think I've I've got that vibe as we've been going through a a few of the projects here. It's like, you're not trying to change the way that people work. Everything just all that experience that developers have, they're they're continuing to use that even though their environment has removed or moved to

1:11:31 to some sort of cloud compute. So and that makes a lot of sense. Like, we we you're probably not trying to rebuild people's habits since they've got five years, ten years of experience of working with their tools. Awesome. Alright. I'll just unshare my screen. Maybe we could start to wrap up and talk about the the roadmap for Gitpod, what's coming next. I'm also really curious about the the pricing. Like, I've not paid anything. I've not given you any card details. All of this is just free. How does that work? How does it work? Yeah. It is we like, Gitpod is available

1:11:46 Pricing & Licensing (Freemium, Self-Hosted)

1:12:12 as a Gitpod IO, which is SaaS service. And and then also there is this Gitpod is open source, so you can also self host it on your own Kubernetes clusters. And for the self hosted version, there is the possibility to, you know, unlock certain features with an enterprise license. We try to keep everything that is very, you know, developer specific in open source and everything that is more, you know, important for larger teams or even companies, managers, and so on. We would put into the the enterprise license. Forget about IO. We have a freemium subscription.

1:12:50 We want to support the open source development. Also, we see this as, you know, kind of a bit different way of developing, like, special especially with automating and having these ephemeral dev environments and so on. So it is really a good opportunity to, you know, lower the friction for open source contributors. So this is kind of a really important thing to have a good freemium subscription so that it can be used in these scenarios easily and people see and understand the value. And, yeah, eventually, we might need to make some money also, of course. But

1:13:32 currently, you know, the focus is really on solving this problem for the developer community. Yeah. Definitely. Can I use Gitpod on the free plan with private repositories, or is that where the the kind of the paying comes in? You can use it for one month in a trial, but then after that, the paying comes in. Yeah. Okay. Awesome. And and what about the the road map then? What what are what are the team working on? Besides those features we that are just currently released in preview, like having Versus code as well as the and also the

1:13:57 Gitpod Roadmap

1:14:15 the pseudo and root support. We need to flash that out some more. We have a feature that Chris built actually a couple of months ago already, which is not entirely rolled out called full workspace backup. That means, currently, we have a certain volume, which is a workspace folder. That is the stuff that we would back up between the the Gitpod sessions. With the new version, everything gets back up. It doesn't matter where you have installed that. We have some other, like, very exciting features, the SSH access, which will allow to use code remote SSH and also what Jetpod is

1:14:52 working on to connect with the pod workspaces so you can even use your desktop IDE in in together with the pod. The collaborative editing feature mentioned before is important. I'm not sure, Chris. I guess I provided about a few things in the road map. I think for the upcoming time, that's that's it. So, we're also the the self hosted version that mentioned, we have convenient installers for those, you know, that make it easy to to install them on on GKE and AWS. And we're looking into, you know, improving those, making those more stable, baking in more and more Terraform support on

1:15:41 that end. So also from that side, we're working on that. Awesome. Well, thank you very much for joining me today. It's a really cool project. I'm I'm hoping that it's gonna allow me to finally migrate to use my Chromebook. I can see even even beyond that on my Mac and on my Linux machines why I'd still prefer this kind of environment as well. There's a lot of benefits and consistency that can be adopted here. And the pull request format was just basic on the cake. I'm really happy with that as well. Is there anything you would like to

1:15:47 Conclusion & Final Thoughts

1:16:11 say or share with us before we finish up today? Nope. Yep. Thanks, David. That's what I wanna say. Like, it's really nice to have this it was also nice note having no preparation for this session, but I also think it's it's really good to have this spontaneous, know, just talk about the product. Yeah. That's good. Yeah. Some people love it. Some people hate it. I'm glad you enjoyed it. I I think we we had a really good look at Gitpod here. I think it's a really cool technology. I love that it's open source as well. So, you know, great job.

1:16:42 Thanks again. I look forward to seeing what happens in the future. And thanks again for joining me. It was a pleasure. Thanks for having us. Have a great day. Thanks. You too. Bye bye. Bye.