First steps with Gitpod – great for try out, quick open source contributions and for workshops

Gitpod.io is a SaaS for software developers (that can also be used in self-hosted mode on Kubernetes). Gitpod makes workspaces available – typically based on a Git repository – with tools to develop and build software. A workspace is an ephemeral (not long lasting) Linux environment that I can access from my browser – from a terminal, browser based VS Code and from locally running IDEs. A workspace is created from a Git repo URL (GitHub, GitLab, Bitbucket) launches with source code, relevant language runtimes, additional tools.

A workspace is intended to be quickly created – and quickly disposed of once the work is done. That work can be development, review, test, training. Applications (APIs, static web applications, even desktop applications) can run in a workspace – in the cloud – and they can be accessed from anywhere. The workspace can be shared (live), to allow pair-programming to people not co-located. A snapshot can be taken of the state of a workspace; this snapshot can be cloned and used by anyone with proper access to the source code repository.

And more good news: The free tier in Gitpod.io provides 50 hours of workspace usage per month (for free!). The paid tiers offer more hours of workspace usage, higher numbers of parallel running workspaces.

I ran into Gitpod.io by accident last week as I was exploring an open source project that indicated it was powered by Gitpod.io. (open source projects can qualify for free usage of the service).

I am initially quite interested for the following use case:

• quickly trying out (to build) an open source project; simply open gitpod.io#GitHub_URL_OF_OPENSOURCE_PROJECT in my browser and I get a development environment with the source code (note: I can use instructions in the URL for checking out a specific branch ).When an open source project includes a Gidpod configuration file (.gitpod.yml) it gets even better: the Gitpod workspace is tailored exactly for the open source project and its dependencies and if one has the Gitpod browser extension installed, there will be a button on the project’s GitHub or GitLab’s repository page for direct launching into Gitpod.

  Of course when I want to make a contribution to an open source project, I will use this same approach – after first forking the repository and opening the fork in the workspace.

• demonstrating development tools and technology: I frequently present on technology used in software engineering and typically a presentation will include one or more demonstrations. Getting a proper environment for a demonstration is always a bit of a hassle, Things have much improved over the years, with VirtualBox, Vagrant, Docker, Docker-Compose, Windows Subsystem for Linux, Visual Code Remote Containers and Kubernetes. However, managing the environments locally still is cumbersome (I am a little bit messy it seems). I have the hope that with Gitpod.io I will be able to define multiple isolated environments for different technologies and different demonstrations I can show my audiences – each of the ephemeral so quickly started, used, discarded and recreated.
• workshops / hands on labs: in many of my presentations I encourage attendees to try things out for themselves. In the distant past, most time in each handson session was lost on preparing the environment, rather than actually trying out the technology of interest. Using vagrant files to spin up a VM and later using Dockerfiles and docker-compose to locally run containers of course improved things. (recent events surrounding Docker Desktop on Windows took us a few steps back). However, with Gitpod, I believe life as a workshop instructor will be much easier. By providing a GitHub repository URL to a repository that contains the sources, the markdown files with tutorial instructions and the .gitpod.yml file to configure the workspace I will allow each participant to rapidly spin up exactly the right environment for both inspecting and developing the source code, building and testing the application and running the application – all from the context of a browser. A browser and internet connection is all that my workshop attendees need. Well that and a Gitpod account (free plan, create from GitHub account)

A Gitpod workspace is a Linux environment that runs as a container (although this is not something you really need to be aware of). The definition of the workspace is based on the base image used for creating the workspace – see this GitHub repo with the image definitions (these are available as open source ). In the .gitpod.yml file, we can refine the workspace base image with additonal instrructions – Dockerfile commands to extend the base image, initialization commands (to run when the workspace is first created) and start up commands (that are ran whenever the workspace is restarted. The gitpod (Linux) user can further run commands in the terminal – including sudo commands.

Geting started with Gitpod

The steps I followed to get going with Gitpod are very simple:

1. Have GitHub account

2. Create a Gitpod account – using my GitHub account

3. Choose the Free Plan (50 hours per month); next level up: Personal Plan (8 euro/month – 100 hours per month)

4. Open the URL https://gitpod.io#<URL_TO_GIT_REPO> – in this case the repository is a private Bitbucket repository. I have to login to Bitbucket to allow Gitpod to clone the resources from the repository.  This repository does not contain a .gitpod.yml file. This means that the default workspace image is used and no special tools or libraries are installed and no initialization is performed automatically (npm install, mvn clean install etc). Workspaces started based on this default image are based on Ubuntu Focus and come pre-installed with Docker, Nix, Go, Java, Node.js, C/C++, Python, Ruby, Rust, PHP as well as tools such as Homebrew, Tailscale, Nginx and several more.

If I want to use this repo more often in a Gitpod workspace, I should definitely edit the .gitpod.yml file to ensure the specific workspace initialization takes place. See this documentation page on details regarding editing this file.

I chose VS Code in Browser as my default workspace type. Gitpod started VS Code in the browser when it had initialized the workspace. I have full access to the source code – as shown below. In the terminal window, I started the build for the application (after running through a number of installation steps such as npm install, installation of ng (Angular CLI)  and several npm modules.

Local build time on my laptop (WSL 2 – Ubuntu) – 1 min 37 seconds. Gitpod build time – after the first time with all the initial downloads –: 1 minute 18 seconds. I would have been happy with on par timing; this is even better. And the whole browser based interaction is very smooth too.

It is still early days for me with Gitpod. And I have not yet ran either a presentation with Gitpod based demonstrations nor a workshop where the participants worked in Gitpod workspaces based on a configuration I provided to them. But that will soon happen I am sure. And I expect to work shortly on a contribution to an open source project (Dapr.io, Steampipe, …) using a Gitpod development workspace.

I will report on my further experiences.

Resources

Gitpod.io Home Page

Gitpod.io Documentation

GitHub definition of Gitpod.io’s base image – https://github.com/gitpod-io/workspace-images/tree/main/base

You can install the Gitpod browser extension in any Chromium-based browser such as Google Chrome, Microsoft Edge, Brave, and others, or in Firefox.