This isn’t a help request, but I managed to leverage habitat in a somewhat novel way recently that I thought I would share in case anyone ever runs into a similar situation. If there’s a better place to drop this, please say so.
One of my hab-managed application recently added a new dependency on a gem that has a binary component that is notoriously difficult to build, and in fact, requires patching of upstream projects to make it run headless because of the X-windows primitives it relies on. All our developers didn’t give it a second thought because they are working natively in OSX, and it Just Works there, no big deal. I of course didn’t find out about this new dependency until things started breaking in deployed environments. Pretty much nightmare scenario from a devops / ops perspective.
After a lot of wrestling trying to get this new dep built in our normal habitat flow, I managed to hit on a solution that would have saved a lot of time had I thought of it sooner. I ended up creating a base docker image that included this dependency from a normal ubuntu distro package. Then for our build process, rather than having habitat do the docker export, I wrote a dockerfile that installed the freshly built hart into the image as if it were a VM or bare metal deploy, and created an entrypoint script that replicates what the hab-exported image did.
In the end, the flexibility of the hab system let me work around the problem without having to invent a bunch of automation to deal with this awful depedency, and create a drop-in compatible image. If I had thought to do this from the start I would have saved days of frustration.
If you’re ever in a situation like this, give this a shot! It might save you a lot of time. It’s not “clean”, but it works! Even if in the end you do decide to do things “right”, this can buy you time to get it done without having other work grind to a halt.