git greenbase means never pulling a broken build

If your team uses Git and Continuous Integration, chances are good that your workflow could benefit from git greenbase. But first, strap on your VR headset and experience the perils of git pull through the eyes of our seasoned developer, Karen.

Karen vs the broken build

You arrive to work still flush with exertion from your morning run, a smile on your face and a bounce in your step — the light bulb went off mid run: you knew why the identity service was flaking out every morning at 11:48AM. Firing up the console, you cd to the right repo and git pull flows nimbly from your fingertips, your heel tapping out the beat to the last song on your playlist; it was a good one.

Git decides it needs to repack and take out the garbage on your oversized repo. You roll your eyes slightly, but no bother — nothing can get you down today. You’re in and out of Vim in a flash. Hard to believe such a simple three-line change would alleviate so much misery for the Ops peeps. You glance at the clock. It just might be possible to get it diffed to code review before the daily standup. Just one thing left to do… Run the tests.

“That’s funny…”

“That’s funny… 17 tests failed???” You furrow your brow in consternation. “How did my change possibly break the Time widget”, you think, shaking your head. Down below, your once merry foot had stopped tapping, its good beats forgotten.

The next ten minutes sneak past you like a puma as you pour over all the source files even remotely related to your fix. Still nothing. A blip on the screen shocks you from your concentration like a cold pie to the face. “You coming to the standup?” Yikes, I’m late!

Skidding to a halt Coyote-style near the great semicircle of agility, you sidle up next to your buddy Anne. Everyone looks faintly amused, but they’re not looking at you. Tom is apologizing for breaking the build.

“Sorry I’m late everybody”, you interject meekly. “I was looking at some tests I broke.”

Tom looks at you sheepishly. “By any chance, were they 17 tests in the Time widget?”

Slumping forward, you let out an overly dramatic exasperated sigh of frustration.

The team glances around for a second, then bursts into laughter. It was a knowing laugh, one of commiseration and mutual understanding.

Where vanilla git pull falls short

What happened to you in our story? You pulled a broken build! That sent you down a rabbit hole searching in vain for a problem you didn’t cause.

You ran git pull to pull in the latest changes, but think about it, did you really want the latest changes? Or did you want the latest good changes? When people build a house, they take time to prepare the land and the foundation. They don’t just start building on a pile of junk. Likewise, when we start development of a new feature or bug fix, we should start from a known good place. That gives you the confidence that any build or test failures really are your fault, and not from Anne, Tom, or that one intern that rides around the office on a unicycle.

If your team practices Continuous Integration (CI) and has a solid suite of automated tests, your source of truth for what constitutes a “known good build” is your CI server.

git greenbase to the rescue!

This is where git greenbase comes in. Instead of blindly running git pull like a slot machine and hoping for the best, you run git greenbase. It queries your CI server for the latest passing, or “green” build, then resets your local master to match. Voila! master is now at a known good state. Start your coding engines with confidence!

What about local feature branches?

If you are on a local feature branch that tracks master, and your team uses a rebase-based workflow, then git greenbase still resets master to match the green build, but it also rebases your local feature branch on top of master. Pretty cool, huh?

Installing git greenbase

git greenbase sits serenely on Github: https://github.com/tygerbytes/git-greenbase. If you’re on Linux, install it like this:

git clone https://github.com/tygerbytes/git-greenbase.git cd git-greenbase ./install

The ./install script will create a symlink to git-greenbase and add it to your PATH. Git will find it in your path and allow you to run git greenbase, just like any Git command.

(See the repo for the latest installation instructions.)

But what about Mac and Windows?

As of March 2018 git greenbase has only been tested with Linux. It probably works with Mac OS X as well. It most likely won’t work as is on Windows. I am totally open to pull requests. If demand is great enough, I’ll write a version in PowerShell.

Configure git greenbase to work with your CI provider

Now that it’s installed, how do you configure it to work with your CI provider? Typically you need to provide Git with your CI server’s URL, API token, and the ID of your project. The information is stored in your Git config.

For example, if you use Travis CI, you would run commands similar to the following:

git config greenbase.provider traviscigit config greenbase.travisci.token <TOKEN>git config greenbase.travisci.serverUri <SERVER_URI>git config greenbase.travisci.repoId <GITHUB_REPO_ID>

(See the repo for the latest configuration instructions.)

Which CI providers are supported?

As of March 2018 the only CI providers supported out of the OSS box are:

• Gitlab
• Travis CI
• TFS (Not well-tested)

That’s a short list! If you would like to add support for another CI provider, feel free to send me a pull request. See below under “Contributing to development.”

Contributing to git greenbase development

git greenbase is written in Bash, and tested using the Bats testing framework.

I tried my best to design it in a modular fashion for testability and maintainability. For example, the logic for communicating with each CI provider lives in its own Bash script, with its Bats tests alongside it in the same directory.

Personally, Bash isn’t my favorite language, nor am I a super skilled Bash developer. That said, I feel tools like git greenbase will bring more peace, love, and butterflies to the DevOps landscape. So I persevere. :)

See the development page for the latest development details.

Can I buy you a coffee?

If you’re super stoked about git greenbase and all the pain it has saved you and your team, buy me a coffee. I find coffee a great motivator.

Originally published at tygertec.com on March 5, 2018.

git greenbase means never pulling a broken build was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.