Gitlab fixed, back on track
by on with No Comments

After my last post, I decided to dive into our Gitlab setup and see if I could fix the problem. In case you’ve forgotten, the problem was the latest pushed code was broken. So, our master branch was pointing to code that was not working when pulled and deployed. The pushed code had changes to the gradle and build setup, not java code, so that’s why it was pretty broken. None of us know git all that well (but let’s be honest, who does?) so it has taken us a little while to remedy our setup.

I dove in and fixed it learning a lot about git in the process. I basically had to create a bunch of temporary branches with my current working code and rewrite history — basically making it look like the last changes had never happened. I set the origin/master branch to my working code with changes.

After this debacle, we decided that we should be using branches more often, keeping the origin/master branch for production, working, thoroughly tested code.

Gitlab restored!
by on with No Comments

Unfortunately, I haven’t been able to do much work on the Field Day Android Application. In order for work to be done on that, Gitlab has to be working. Gitlab is where all of the repositories of our code live. And at the beginning of last week, Gitlab was broken.

Gitlab broke due to an accidental upgrade. It was upgraded on hopper from 7.14 -> 8.01 which is a massive upgrade. In versions > 8, there are 2 proxy servers — one the serves git requests (merge, commit, etc.) and one that does authentication. So, that broke Gitlab because there were additional configuration files to create and edit after that upgrade. So, I attempted to downgrade to the version we were using before (7.14) with yum. That was a bad idea. The downgrade with yum isn’t bulletproof and messed up some config files in the process.

Sigh, I upgraded back to 8.01 and tried to find the error. Apache, proxies, and web sockets. Gitlab uses proxies and web sockets, something that Apache (the web server running on hopper) isn’t particularly great at right now. Gitlab really wants to use another web server called Nginx (really, really wants to use Nginx). It even comes bundled with an Nginx install. I tried and failed many times to configure Apache to work with Gitlab and sockets and proxies, but it didn’t work. I couldn’t change the web server on hopper because there are other things relying on it.

I decided that Hopper is probably not the best place to put Gitlab. Alas, I moved it to Dali. Dali has a lot of space and is not running any web servers.Everything on the user side is the same, it just lives on a different machine now.

Fortunately, Gitlab comes packed with a way to create a backup of everything and restore from a backup. I created a backup of the current database, repositories, etc on hopper, installed Gitlab on Dali and restored from the backup I created. Poof. 8.01 is now running on Dali and can be accessible at gitlab.cluster.earlham.edu. I even went ahead and set up email notifications for push requests to repositories for the projects in field science and others that I’m working on.

Also, 8.01 is a whole lot better that 7.14 and much prettier!

Screen Shot 2015-10-26 at 1.35.30 PM

Gitlab, and archiving!
by on with No Comments

FINALLY, we have a stable Git environment. On hopper (cluster.earlham.edu) I’ve set-up something called Gitlab. Gitlab is an open source git repo hosting environment. For those of you that are familiar with Github, Gitlab is like a self-hosted version of that. I chose Gitlab because it’s private (in Github, you have to pay for a premium membership to have private repositories) and it’s cleaner and has better access control than just doing it through a user’s directory on the machine.

You can see the Gitlab setup here – Earlham Gitlab. There’s a group called field-science where we are going to host all our code. I’ve already created projects for our Android work. The old android code is now in the archive-android project. This means that it is read-only! Yay! Starting fresh for Android $FIELDSCIENCE app. There’s a new project called FieldScience that we will use for the new app, which I’ve already created the shell for in Android Studio and pushed it to the Gitlab. Yay for cleaning and organization.

On Gitlab, we will store the visualization code, the database code, the arduino/sensor code. All the code! This makes it a lot easier when trying to find stuff later (our old Arduino code is all over the place).