Community Office Hour: Gitpod CLI

Company
Gitpod

Date published
Nov. 30, 2023

Hi everyone, I think we are live now. Thank you so much for joining our community session today. If you're already here, please drop by in the chat to say hello and tell us where you're calling in from today. I'm Pauline and we also have one of our product managers backstage who will be running the majority of the session and talking through the upcoming feature, the Gitpod CLI. But before we get started, in case you're not familiar with GitPod or cdes, our mission is to remove all friction from the developer experience through increasing velocity, collaboration and control, and ultimately empowering developers to be ready to code. And GitPod is a developer platform that provides on demand cdes or cloud development environments to create software faster and more securely. I'm sure that. Oh, I can see a few comments in the chat already, so very familiar community members already. That's great. So you can actually spin up a CDE today over at GitPod IO, we have two offerings, cloud and dedicated. But yeah, if you want to find out more information about them, feel free to go over to our websites. Without further ado, I will pass on to Lou. As I said, this session is going to focus on an upcoming feature, the gitpod Cli. And yeah, if you have any questions throughout the session, feel free to just drop them in the chat. We'll try and make this as interactive as possible. So. So I'll jump in, share some questions that come up to Lou, and yeah, we'll just try and make this as interactive as possible. Awesome. Without further ado, I will add Lou to the stage. Hey, hey, hey Lou, how are you? Hello. Can you hear me ok? Yes, all good. Cool. So let's jump in. Also, I've shared my screen. I don't know. Yes, I've just added it. Awesome. Cool. Yeah, so hey folks, for those that don't know me, my name is Lou and I work as a product manager over here at Gitpod. So what I want to go through today actually, is an upcoming feature called the Gitpod Cli. So I will do a very brief introduction. Actually just dive into demoing it and just playing around with the CLI itself. So if you're joining us live, please do ask any questions because I can just answer them real time. I want to focus mostly on the demo today. I think just showing it is what makes sense here. But before we get into that, I'll just do a quick run through. So I'll give you a bit of background, jump into the demo and then we'll get to questions. So basically, Gitpod is introducing a CLI. This is currently in private beta. So if you hop into the discord after this, which is at Gitpod IO chat, I believe, correct me if I'm wrong, Pauline, but then if you hop in there, we can give you some more details about how you can download it, you can play around with it and give us some early feedback. But the plan is this will be released also in a couple of weeks. So if you're watching this in the future, then this might already be a thing out there, if you go check out our docs. So a few things to note about the CLI. So the CLI is basically mostly around personal workspace management currently. So what I mean by that is, it is for interacting with your own personal workspaces. In future, we might have an extension for this that allows you to sort of administer workspaces and do things more at the administration or organization level. But for now, this is very much workspace management at the personal level. So it's managing your own personal workspaces for those not familiar workspaces, essentially just the environment that you work on inside of Gitpod. It's your ephemeral workspace where you, you do all your coding and all your development inside of that workspace. The second thing is, automation is enabled, so even though it's personal workspaces, you can also automate this. We'll talk about this in a second through a sort of login option here, which is to use an access token. And that means that you can run the CLI in continuous integration or in some form of automation. If you wanted to run things on a cron job or on a specific schedule, you can also do that as well. And also the existing CLI. And I'll talk about this a little bit later. That exists within gitpod right now, which is called GP, which exists in the workspaces, will be called the workspace CLI, and that will exist. So what that means is in the future, there will be two clis, one for the controls the workspace itself, and then one that controls starting workspaces and listing workspaces. If you think it's almost like one that's internal and then one that's external as well. But before we get into the questions, I will just go ahead and we'll just do a demo. Pauline, if you want to, if there are questions that come up, let me know, just stop me and we can, we can talk about that as well. But otherwise, you should see my terminal and if you can't, then also let me know. But so one thing you can do is to install this. Actually, you can install it through brew. So those watching along, if you are on a Mac, you can also install this through brew. I've also, I've already got this installed, so it's going to tell me that it's already installed. If you run that on your machine, that's going to add it also into a path as well. So you've got that available. If I go ahead and run the actual Gitpod command, and we just see the help information that we've got here, so we can start to have a look at what things we can do. So I'll run through some of these today as also login, which is logging into the ClI, who am I? Which is also looking at who you are as a user. You can list workspaces, create them, open them, stop them, so that kind of thing. So you can start to explore and experiment with your workspaces directly from your terminal. So if I go ahead and, and imagine that I've actually just downloaded this now, one thing that you can do is go ahead and log in now, depending on how you're using gitpod. So we have two different offerings of gitpod. We have Gitpod IO, which is called Gitpod Cloud, which is our sort of managed gitpod. And then we also have a sort of private version of gitpod called Gitpod dedicated. So if you're using gitpod dedicated, you'll have a custom URL, which means that you can go in here and add in that URL in here. So let's say that is this organization gitpod IO. Add that into your host, and then it will run the login command, but it will authenticate against that separate instance. Since I am not going to use this against dedicated today, I'll actually just run this against my Gitpod cloud account. So once I do that login, it's going to ask me which organization I want to use. I'm going to pick Gitpod in this case, and what that's going to do is now it's going to give my Cli the context of that current organization. So that's gitpod. If I want to bring this back up again, I can just go ahead and run Gitpod, who am I? And that will give me information about who's logged in user, which is the organization that I'm looking at. So at any given time, you're also managing and looking at workspaces within a specific organization. If you're undedicated right now, there should only be a single organization per instance. That's just a limitation of gitpod dedicated today. So you shouldn't need this. You should need to swap organizations if you're on dedicated right now. So let's go ahead and get started. So if I look in here, so one thing I can do is I can start off by actually listing out the given workspaces I've got. So if I go in here and type in gitpod workspace list, I've created a whole bunch of workspaces before, and then we can see all the different workspaces I've got, including the status whether or not that workspace is actually running or whether it's stopped. I can see which repository that's open for, and then also the branch. What I can do, if I bring this back up again is I can, then what I can do is create even a workspace from scratch. We'll do that. And then also what we'll do is also open a workspace as well. So you can see how that looks. So if I do create a workspace from scratch, what I'm going to do is create that for this voting app repository. Now you can pass in any different repository you want here. This works the same as if you're using Gitpod in the user interface, and then it's going to create me a workspace based on the GitHub pod yaml that exists within that repository. So I go ahead and hit enter on that, that's going to then make this request, it's going to go start setting up that workspace and creating it for me. So if I just drop out of the logs there and just mention that actually for this command you can pass some different arguments. So one thing you can do here is you can basically tell this command that you don't want to wait. So if you want to launch the workspace but you don't want to have this interactive output, you can pass in this flag for not waiting. You can override the default editor here. So if you have a user preference set for your editor, you can override that at this point and specify what editor you want to use that workspace. By default, the workspace create command doesn't actually open a terminal or your editor, but if you press the open command, it actually will do that by default. So it's going to start the workspace and then open it for you as well. And then finally you've also got the SsH command, which actually I will let's have a go. So let me create another workspace here. And then actually what I'm going to do is pass SSH command. What that will do is create that workspace, start that up for me, and then it's going to directly ssh me straight away into that workspace. So again, for those that are unfamiliar, the way that gitpod works is it spins up a workspace or an environment, and it goes and reads a yaml file that you declare at the top of your repository that declares all the different steps that you need to take in order to make make that repository working. So then what you're going to do here is then it's going to spin that, it's going to run through all those steps that I defined, and then it's going to drop me straight into that workspace. And you can have as many of these workspaces as you want. If you want to create them in parallel, you can do, and you can work on multiple tasks, whether that's running, doing a pull request, or doing a piece of work, or doing a spike for an investigation, you can have different workspaces for that. So wait for that to run through and spin up for me. Let's just create it now. And then what we'll do after this as well is we can have a look at some of the other different commands for stopping workspaces, deleting them, and then some of the different options you have around editors as well. So I have to pray to the demo guards. This will workspace will come up in just a second. In fact, whilst that's running, I will just go ahead and fire up a separate terminal because we can have a look in here as well. So if I go back in here and go back to my workspace list, I can see that I've now got two running workspaces and one that we've just created there. That's creating, but let's say that I've got those and I've already started those. What I can do is I can also run the open command to actually open one of those running workspaces. If I go in here workspace list, and then I go workspace open, what I can do is I can grab one of those running workspace ids and then pass it to the open command, and that will actually just directly open that workspace. Now that workspace itself, my editor preference is in the browser. So what that's going to do is open up with versus code running in the browser. Apparently it's using my light theme from before, but then what you can see is for that repository, I've got everything in here that's already started running. So it's run through all of my steps in my gitpod yaml, and then I've got all my different tasks here that already started and running for me as well. So if I go ahead and I let's have a look at that, see if the other workspaces started now. So there we go. So this is the one that I started previously with Ssh. And what you can see here, this is the command from before start workspace, and it's just dropped me in and inside of ssh. So I'm now inside the actual running workspace and I can run different commands in here. I typically use fish shell, so I'm just gonna open it up using fish as well. And what I mentioned before is the GP command is also still available. So now I'm inside of a running workspace, and now I have access to different commands that are available through the GP CLI. So that's things like if I go in here and I go gptask list, I can see the number of different tasks that I've got running, and that is the same task that you have, for instance within versus code. And you also see this within jetbrains. So here are my running task terminals here inside of the editor, but here's the same representation also in the CLI. So same thing for ports. You can see all the running ports information and modify those as well from within the workspace itself. Do feel free to stop me polling if there's any questions, because I can answer those as well if needs be. Yeah, I actually have a question myself, but I'm also waiting. Okay, I was just wondering, I saw that you had, there was multiple flags for the CLI. Are there any other flags that are currently in development, or is that it? For now, short answer is yes, long answer is it also depends. So there's lots of other things that we're thinking about. One of the reasons for doing this demo actually was also to get sort of feedback from the community about what's the most helpful for them and what's kind of missing. One thing that we've, that we certainly want to help out within the short term as well, is so right now, when you do gitpod workspace create, I'll give you an example of one right now at the moment you pass through the repository URL, one thing that we do want to do is make it easier as well to start from local as well. So one thing we'll add in there is a command also to start from locally running git context as well. So if you're in a repository locally, then you could run we haven't yet decided on the API, but it will probably look something like this, which is like workspace create, and then probably something like Dot, which references then the current directory, and then it will create you a new workspace based on your sort of local context. So you don't have to necessarily then type out like the full URL. That's something definitely will come in the short term. Other, other things that we're definitely thinking about as well is also increasing sort of the access scopes as well. So right now you get these are the workspaces that belong to you, but also thinking about providing access to across a whole different, across a whole organization which unlocks use cases, for instance, managing those workspaces across an.org. If you wanted to shut down every workspace at a specific time, let's say over a weekend, you could do that as well if you wanted to run out on a cron job inside of automation to do cleanup. If you wanted to enforce some sort of policy where developers only had one or two running workspaces, you could also enforce some of those things using some of the CLI commands at the admin level. So that's definitely something we've been thinking about as well. Awesome. We have a question from Shel. His question is, what does gitpod completion do? Okay, that's a good question. So at the top level you've got here gitpod completion. I don't think so. This is basically providing your auto completion. Don't have an example actually of using this with the different shells currently, but I believe what it does is if I do gitpod completion and I go into fish, it should basically gives me all of the autocomplete information. So this is the fish shell configuration that you would then put into your configuration file so that you've got the autocomplete of these commands. So here, if I was to fill in a new command that I hadn't typed before with fish, I get my historical ones, but let's say if I was writing out a new command that I didn't have, like by having completion, it's going to fill in on your ClI, basically those commands that you don't actually have. So it's going to give you the flag suggestions and the command suggestions as well, but depending on the different shell that you're using as well, we will provide some snippets in the docs as well. So you can take that output and automatically put it into your configuration as well for the different shells. Awesome. Do you want to continue with your demo, Lou? And I'll wait for more? Yeah, I don't know how much more necessarily to show majority of it there. Let me let's actually create a workspace and then actually pass an editor. I think that's probably a useful one as well. So if you just create a workspace without passing an editor, what it's going to do there is use your actual workspace preferences. So if I go into gitpod cloud for myself, go into the settings and I go in, that's the organization, sorry, in here. So I've got my preferences for my editor. So by default I'm using the browser, but if you specify this differently, then it's going to start using that default. What I've got now, so what I've run here is now I'm starting a new workspace and I'm also specifying an override for the editor, and then I'm telling it to open that directly as well. So what I've got that now doing is created this new workspace and it's fired that up for me. For users who are using VSCO desktop, you might be familiar with this, but you also have the gitpod extension here as well. From here you can actually also directly swap between running workspaces as well. You can use that command to start launch you into versus code just on your machine, so you don't have to be in the browser or you don't have to be through SSH, but directly in versus code. Then you can actually then even swap to some of those different contexts. This is now running all my different tasks for this specific workspace, but if I wanted to, I could disconnect from this. This is going to just disconnects me from this remote development connection to that workspace, but I can even swap just to a different one as well. So one of those running workspaces that we already started now I basically just swapped over and now I'm looking at a different workspace as well. So you can quite easy to multitask even inside of versus code, and you can start to use these different interfaces. Whether it's the CLI or the extension inside of versus code really depends on what you're doing and what your sort of preferences are as well. So that's that I have of I see all of your questions, but I have another question for you, Lou, before I think it sets the scene a little bit before Ophelia's questions. Sorry if you went through this and I missed it, but can you trigger a pre build using the CLI? Can you do anything related to pre builds from here? It wasn't that clear to me, not currently. So the pre built settings still apply. So if you go and create a new workspace, and there are pre builds already for that, so you will actually figure out the associated project configuration if there's pre builds with that, and then you'll get the pre build for those, I suppose. Not aware about prebuilds as well. So pre builds are ways that you can run some of these your gitpod yaml tasks ahead of time asynchronously. So basically, if there is a project already associated with that, it's actually going to pull and use the prebuilt anyway. You can't currently alter pre built settings from within the CLI. It's more about just launching workspaces. Prebuild is kind of the configuration side of the workspace almost. And then here it's mostly just about launching workspaces for now. Might change in future. Yeah, that makes sense. Kind of related, I guess. Can we get a notification or a command to check status of when command tasks in the gitpod yaml finished running notification? I suppose you could do with some sort of shell script magic. It's not something that we support out of the box that I'm aware of, but it's kind of interesting. But it's interesting what the use case is there. So you want to have a native notification when uh, the workspace started, I suppose. Um, it's certainly something we can look into and maybe we can provide, like um, if there's something open source or a third party. Because the, the thing that's neat about the CLI, right, is the way that you can compose it with existing tooling. So there's nothing for that natively, um, in the CLI today, um, if I'm understanding it correctly. Anyway, so awesome. Um, another question. Does a workspace that was started using the CLI have the same timeout as a workspace that was started in the browser? So 30 minutes. Yeah, this is a good question. So the way that the CLI still respects your timeout. So the way that timeouts work is you can also set those as a preference. So you can set to user level, you can set a default workspace timeout. And what that does is basically if you're not using that workspace actively, that is, there is no sort of connection from the editor or the terminal in terms of typing or sort of user activity detected that will then spin down your workspace. The CLI itself respects those existing, existing setting on the timeout. But one thing that would be certainly interesting is also being able to pass that through the CLI. That's not something that's possible today, but it could be like a very interesting, I think, extension as well. So just in addition to having these other flags as well, like you can override the editor and you can override the workspace class as well. Let me pull that up. I think having the timeout there would also be very interesting, but it's not possible today. You can't overwrite the timeout here. Instead it will use or inherit from your user settings, so it will pull this default one. And the way that timeouts work is it depends on the interface. So inside of versus code, it's checking for certain events. When you're editing inside that, inside of SSH, it checks on some aspects of the connection and some of the data that you're sending back and forth to the workspace to detect whether or not you should keep that workspace alive or not. And we have some, some documentation about that that's worth checking out as well inside the docs, if I pull that up, if you go in here into workspaces and then there's a workspace lifecycle one, and there's a bit more information under here about timeout specifically that talks a bit about how timeouts work, but the CLI continues to respect the behaviors that are defined here. Awesome. I hope that answered your question. There was another question here. Can we manually launch prebuild for a repo using the CLI, which I asked. I feel like you answered that already, Lou, but in case. Yeah, awesome. Another question. Would you want to have that just for the tasks or other processes within the workspace? Eg, when you manually start a build, could you repeat that? Would you want to have that? Oh, I guess it was referring to what you were talking about earlier, but would you want to have that just for the tasks or other processes within the workspace? For example, when you manually start a build, do you remember the context of it is there that I'm trying to figure out? Yeah, Chris, if you could give us more context. I completely forgot as well. I was like really into this pre built question. Ophus said, yes, that could be that could be useful for many things. Initially I was thinking about all tasks in Gitpod YAMl, because that's means the workspace is now ready for QA. Oh, okay, so you're talking about sort of indicating not just if the workspace is created, but then also if all of the running tasks are up and ready. That's a very interesting use case, one that the CLi doesn't give you just yet, but is also one that I definitely heard from lots of different users and customers as well. So definitely would like to hear more about that one. I'll reach out about that one specifically. The short answer is that the CLi doesn't do that just yet. It would be interesting to explore if you could write a custom script for that as well. I'm not sure. Nice. There's another question here, a little bit off topic, but does this mean the API for workspaces is done and will be made public? So what we're talking about today is basically just this CLI interface. Of course under the hood this does use a certain set of APIs, which is also being, which we will at some point also release. That's not something that we're doing today or it's not planned just yet, but is also something very much that's on our roadmap and hopefully will come soon. I don't have any more concrete information I could share about that. We really want to do kind of get this CLI out and release to users first, but yes, watch this space, because the API will also quite likely be coming quite soon as well. Awesome. Does anyone have any more questions? Feel free to drop them in the chats now. And yeah, Lou, is there anything else you want to showcase here whilst we're all still here? I think we covered most of it because we showed starting a workspace. We showed opening in the different editors, we showed opening it directly with SSH and then actually using the GP command once you get into the workspace, trying to think if there's any other of the major things that we didn't go through. Of course from in here, I suppose the last few things is the cleanup stuff. So you can also stop and delete a workspace in here. Let's go ahead and do that as well, just for completeness. Why not? So if we take this workspace id here, and then we're going to go ahead and stop that and then eventually delete it as well. So Google workspace, stop, stop that individual workspace, and then I'm going to come out of that and just go back to my list because then you should see here. Okay, cool. So that's the one there that's stopping. And then at some point that will also then stop entirely and then we can delete it if I want to. I can also delete a workspace as well. So let me grab this one and I'm going to just delete that one as well. So same API again. And then what that's going to do is it's similar to stop. It's going to stop the workspace first and then delete it as well. So if I reopen this again, I should see two stopping workspaces as well, or the other one might have already stopped. Maybe they both stopped. Now I didn't pick that one up for some reason, but okay. But I think that's mostly it. There's some additional commands in here for just referencing some of those values that we talked about earlier on, like the editors or the classes that you might want to pass into commands, but that's more just metadata that you can use to pass into the other arguments and it's kind of it. So yeah, one thing that would be very interesting to hear about, certainly also in the community. I'd love to know basically what you want to do with it. So now that you've kind of seen this, I would love to know what you sort of expected from the CLI, like what kind of use cases that you were thinking about, different things that you can do with it, or what are those things that you're close to being able to do but can't do. We certainly want to hear about all of those as well. So we can take that feedback and then hopefully also provide some further updates, additional commands, different use cases as well on top of this. But yeah, very, very curious as well to see what the community does with this and how can people access this today. So we'll send some information, I think, over in the community. So this is currently in private beta, which means that we'll have to send you some preview documentation in order to get the installation instructions to download it. I showed it at the start, but the brew command is actually quite easy to remember. So if you do brew install and Gitpod IO and then Gitpod, you can install the actual CLI. But we'll share this also in the community as well. If not also wait a week or two, and then also we'll be doing the sort of full announcements and all the documentation will be up to date in a couple of weeks time as well. Awesome. I don't think there's any more questions, so we could finish it off and wrap it up there. Lou, unless you have anything else you want to share right now. I don't think so. I don't think so. Not for now. Okay. Amazing. Well, thank you, everyone, for joining us for this community session. Again, if you have any more questions or you want to share a use case with us, head over to gitpod IO chat and send them over in there. We'd love to hear your feedback and your comments. I think that's pretty much it for today. Thank you for joining.