I’m a Contributor Now: What I Learned from My First Public GitHub Pull Request (and What You Can Do With It)

I’ve made it. I can now say I have done a PR on github on someone else’s repo, which makes me a bona fide contributor.

I know some of you “dev types” are reading this with furrowed brow and arms folded hurumphing about how you, “did 4 PRs this morning while crapping a lightning bolt.”

If you’ve been reading this blog long enough, you know that your lack of support for someone new to the process is . . . what’s it called? . . . oh, right . . . a “dick move”.

I am a contributor to this repo owned by Chris Lynch on github. Feel free to peruse the README if you like, but this is a powershell script paired with a dockerfile that will create a docker image with HPE’s HPEOneView Powershell module ready to use.

Is Doing That a Big Deal?

Maybe. The side lesson here is that the idea of encapsulating functionality into a Docker container, I have found, is becoming more and more common.

Why? . . . Because Kubernetes, that’s why:

Ansible Tower now uses Execution Environments, which are containers that have all the code you need to run your playbooks and collections self-contained.

Want to have Jenkins spin up K8s pods with each job it runs? Create a container image with all the code needed to run everything and call it from a Jenkinsfile.

Why is all of this a big deal? Well, for one: dependencies. I have maintained full-fledged multi-purpose Jenkins before and all its plethora of plugins.

It’s not fun.

Also, with this comes the ability for the developer to maintain their own code infrastructure. We don’t need the Powershell Jenkins plugin anymore, we include it on the image for the container/pod.

What Does the Repo Do?

The real world example is that the code I have contributed to (shout out to Chris Lynch who started this all) was inspired by a real container we use in production. I built a multi-purpose image that has all the running code I need including the HPE OneView Powershell module and PowerCLI.

It’s not really something I can share, but I did show you how to do it in my second post on Containers.

What I Learned from the Experience

Here are some lessons I am passing on:

1. How do you start contributing? Well, for me it was using the repo that Chris Lynch created and finding it valuable, then extending the functionality from there. Branch it, and off you go. For me, it was a useful tool. I also gave the owner a heads up as well.
2. I learned that my Powershell skills could use a refresher. Mr. Lynch taught me about ValidateSet. Way easier than conditionals to check input.
3. I knew this already, but contributing to someone else’s codebase and staying true to it is way harder than creating your own. While I was trying to get the Powershell script to work, I said “. . . That’s it. I am dong this all in bash!” But I would have felt like I was abandoning the original intent. Maybe in ensuing releases I will have both a powershell script and a bash script to build the container?
4. Collaboration can be fun. That’s it. That’s the tweet.
5. No matter how finished you think it is, you will think of improvements, but only after the branch is merged.

If you have a chance to contribute to a repo, I highly recommend it. Looking for a repo to which you can contribute for practice?

Maybe, if you’re a good reader, I will let you contribute to one of mine.

Hit me up on twitter @RussianLitGuy or email me at bryansullins@thinkingoutcloud.org. I would love to hear from you.