I'm a huge fan of GitLab, and make no secret of it. Pretty much my entire CI/CD section of site is dedicated to GitLab CI. I'm actually starting this article whilst wearing the t-shirt they sent me for my blog post on why I use GitLab, where I compare it to GitHub (still a good product, but not my preference).
A Little Bit of Background
Historically I've always shied away from contributing to Open Source projects because I worry that they would take too much of my free time, or that I simply wouldn't be able to make any meaningful contribution. I decided to change that after seeing the following tweet:
I figured that changing a couple of CSS classes on buttons would be a great way to get started, and contribute to a project I love, and use daily. Perhaps not meaningful, but getting it up and running might set the wheel of bigger contributions in motion.
After following the instructions on the various pages from the GitLab Developer Contribution Guide, I was ready to get started. It took a few hours to get up and running, but when it was done I made the changes. It only took 5 minutes, great! And then came the time to test my changes.
My personal laptop is an Asus ZenBook, with an i5 processor, and only 8GB RAM. I got it because a) it was cheap; and b) I normally only deal with PHP, so didn't need a massive amount of RAM.
Running everything needed to get GitLab running with the GDK completely froze my machine. Really. I couldn't use the mouse, keyboard, or even watch the clock change time for 5 minutes at a time. I really wanted to submit my changes as a merge request, so I used one of my work issue laptops to test the changes and make my merge request. All the same, I was disappointed I couldn't do it with my own equipment.
After Tweeting about my experience of the time taken to get up and running with the GDK (GitLab Development Kit), I got a response inviting me to try the cloud based version of the GDK. Being the shameless fanboy of GitLab I am, I jumped at the chance to be the first one outside of GitLab to try it:
Cloud GDK - Getting Started
Having the GDK in the cloud is huge. Not only does it mean you can contribute from anywhere by developing within a browser, it seriously lowers the barrier of entry for someone wanting to try their hand at contributing. You don't need 16GB RAM to do it. You don't need to install PostgreSQL, Redis, Ruby, and I can't remember what else the GDK installed. You don't have to worry about developing on a supported OS (Mac or Ubuntu) to be able to contribute - it's all there for you.
The cloud GDK utilises Gitpod. which is free for up-to 50 hours per month. Like I mentioned, it has everything ready there for you to get started with development. If you are going to spend more than 50 hours per month working on features, then you can double the minutes for 8 Euro per month, or unlimited minutes for 23 Euro.
First set-up with the GitLab GDK took around 15 minutes to go from initialisation through to displaying the login page for the local version of the application working. That is the version you access to test your changes. Significantly lower than roughly 3 hours to get the environment set up locally.
First Changes From the Cloud
Eager to actually do something useful with the access to this resource,and fresh off my first merge request with button changes, I picked out another one of issues in the same epic to look at. This change was never going to set the world alight with its contribution, but would afford me a chance to look at the ability, doing something I am vaguely familiar with.
Issue #231072 was the one I picked at random. Turns out it's only a single file change, but something worthwhile all the same. Into the editor (VS Code, I think, based on being able to use your favourite VS Code Extensions).
The console window (where the Tanuki is on the screenshot above) is a Linux/Unix terminal with Git already installed, so creating the new branch to work on from there was as expected. New branch created and it was time to hunt for the file. Unlike the locally installed GDK where you have all kinds of folders to think about, this puts you right in the heart of the gitlab folder, so you can do your work with no distractions about things like elasticsearch, gitaly, gitlab-pages or other folders (yes, I looked those up in the terminal on my laptop).
Straight into the IDE to find the files, and you notice instantly that it's responsive. You don't notice that it's a browser window working on the code somewhere. Honestly, you'd swear it's a native application. Changing the code is a case of finding where you want/need to make changes, and then making them.
The IDE has the terminal windows docked at the bottom where you can perform your Git actions if that's your style (it certainly is mine). For those not comfortable with the Git command line, fear not! On the left of the screen is the typical Git fork icon. That gives you a nice, easy way to see what has changed, and be able to perform your commit in a more visual manner. This side window for Git also has a very easy manner of amending your commit messages, in case you notice a typo before pushing - or otherwise want to change the message. My only issue is there doesn't appear to be an easy way of cancelling that edit option if you decide against it.
Beyond that, any problems were purely user error on my part. I regularly forgot that it was a browser based IDE, so when I went to refresh the changes on the GitLab preview pane, I'd refresh the full workspace window. On top of that, It's not an IDE I am used to. I use JetBrains products, which have live save. I've actually forgotten that I need to save my work in an IDE, so when changes weren't ready to add or commit, I was left wondering why.
Overall Verdict
I am writing this at the end of the first night of using the product, but first impressions are good. I've literally had it running for 2.2 hours in total, but I have enjoyed the experience.
It's going to take a little getting used to in order to contribute effectively, especially when I'm used to working with my own IDE setup and shortcuts. That said, the ability to edit code within the browser is a worthy trade-off for not having my normal shortcuts available.
The greatest aspect of this whole area is the lowered barrier to contributing. There's no longer a need for a fast disk, loads of memory, or hours of configuration to make a small contribution. It also will allow people who normally contribute using a desktop machine will be able to continue their contributions when they are on the move - assuming they have a device and Internet connection.
Top comments (3)
Great work, Gary!
I chuckled a little when reading about the tab refresh 😅 it's a feeling I am very familiar with. I have too been using AWS Cloud9 while I was taking a Cloud Engineering course and I often restarted my whole workspace when trying some fancy IJ shortcut.
After a while, I changed browser shortcuts so I wouldn't mess up my work.
Great article!
I'm glad I'm not the only one to have these issues with web-based IDEs.
I think after a short time you'd work out those muscle memory kinks, but you'd need to use the web based IDE full-time for that to be any use
Trust me, I've heard this from pretty much anyone 😅
They're very nice, but I think we're a long way from using Web IDEs all the time. If you have to travel a lot for work, and you're stuck on a plane or the underground you still want to work on your projects...
The time away from home it's actually the most productive for me 🤔 except for the announcements there are absolutely no distractions!