Experiments with Go + Git on GCP

Disclaimer: I have had minimal experience with Go as a language and Git as a tool owing to my job role being more focussed on the build, administration, & support of systems. So what follows is DEFINITELY basic knowledge, but I’m hoping that somebody who’s on a similar learning curve finds it useful.

What we will be doing: Setting up a development environment for running and compiling a Go program on a GCP Linux VM and committing it to a Git repository.

Requirements:

1. A free-tier GCP account
2. A Github account
3. A little bit of patience + willpower

Step 1: The set-up

1. Since Google explains this better than I can, first set up a free-tier account and create a GCP VM following the instructions on link.

2. Start up & SSH into your VM. Execute the below command to update the newest version of the packages in the repositories.

sudo apt-get update

3. Install git CLI with the below command

sudo apt-get install git

4. Get the binaries for installing Go into a directory of your choice by executing the below command there

wget https://dl.google.com/go/go1.14.linux-amd64.tar.gz

5. Untar + Unzip file to /usr/local

sudo tar -C /usr/local -xzf go1.10.3.linux-amd64.tar.gz

6. Set the Path variable [DO NOT forget this step. None of the go commands will work if this step is skipped!]

export PATH=$PATH:/usr/local/go/bin

7. You may optionally test your go installation with the example on the Official Documentation page.

8. Install make in case you wish to use Makefiles in your Go application. I found this article by Sahil Muthoo extremely useful and well-written for a good primer on Makefiles for Go, specifically. Since I made use of this during my experiments, I will be writing the rest of article assuming you’re following along on the same track, as well.

sudo apt-get install make

Errors I encountered in Step 1:

1. It was a bit of a challenge finding the latest Linux package for Go, since I was previously doing a Windows installation for the same exercise [merits another article altogether]. Please make sure to select the correct Linux package. Elementary, my dear Watson but extremely important!
2. Setting the PATH variable. Somehow, there was a deletion of the PATH variable when I shutdown my GCE VM the first time, and I ended up going down a rabbit hole unsure as to why it had been deleted. Luckily, just re-executing the command worked for me.

Step 2: Ready, Get, Set, Go!

1. Cloning a git repository onto your GCE VM can be achieved with a fairly simple command

git clone <link_to_repository>.git

2. In my case, I had a pre-existing application written in Go replete with Makefiles to modify. Once the modifications were done, you can either execute:

go run xyz.go

OR

make <whatever vowel you choose to associate in your Makefile with go run xy.go>

3. Once done, you will need to execute these in a sequential order:

git add <whatever files were changed>

git -m commit “Comments_about_the_change”

In the event, you are working on patches that require you to signoff on a particular commit you can refer this link to provide a signoff. Alternately, you may change global/system config for git using the below:

git config — global user.name “xyz”

git config — global user.email “xyz@xyzmail.com”

4. Once done, you can push your changes using the below syntax:

git push <repo name> <branch name>

I was working with the master branch since it was just an experiment, however the best practice is to dedicate different branches to different patches you may want to apply.

Errors I encountered in Step 2:

1. So, as a relative novice, I encountered an error because I didn’t explicitly add the changed files before committing them. A good explanation of why I encountered the error and why git add is so essential is given in this Stack Overflow link.
2. Also since I was working with two different ID’s — one for my GCP account and another for my Github, I ended up declaring my Github username/email as a global variable before being advised by Marky to commit with just — signoff appended.
3. Also, less an error but more of a best practice — I don’t recommend working directly with master branches if multiple patches are involved.