We are going to create a build pack that will facilitate the development and delivery of applications written in Go and with MongoDB as the datastore. Given that there is already a pack for applications written in Go (without the DB), the easiest way to create what we need is by extending it. We’ll make a copy of the go build pack and add the things we’re missing.

The community-based packs are located in ~/.jx/draft/packs/github.com/jenkins-x-buildpacks/jenkins-x-kubernetes. That’s where those used with Kubernetes Workloads types are stored. Should we make a copy of the local packs/go directory? If we did that, our new pack would be available only on our laptop, and we would need to zip it and send it to others if they are to benefit from it. Since we are engineers, we should know better. All code goes to Git and build packs are not an exception.

If right now you are muttering to yourself something like “I don’t use Go, I don’t care”, just remember that the same principles apply if you use a different build pack as the base that will be extended to suit your needs. Think of this as a learning experience that can be applied to any build pack.

Fork the repository

We’ll fork the repository with community build packs. That way, we’ll store our new pack safely to our repo. If we choose to, we’ll be able to make a pull request back to where we forked it from, and we’ll be able to tell Jenkins X to add that repository as the source of build packs. For now, we’ll concentrate on forking the repository.

Get hands-on with 1400+ tech skills courses.