Ruby builds fail when interacting with shipctl or using postgres service

[chris72205]

Description of your issue:

I am unable to run anything that uses shipctl or use the Postgres service when specifying language: ruby. I've made various config changes and they all seem to fail if the image is Ruby.

Builds:

• https://app.shippable.com/github/supplypike/deductions-coordinator/runs/12/1/console call shipctl
• https://app.shippable.com/github/supplypike/deductions-coordinator/runs/29/1/console postgres service
• https://app.shippable.com/github/supplypike/deductions-coordinator/runs/21/1/console shipctl works when language is nodejs (expectedly fails on next ruby specific step)
• any other builds for this project

[a-murphy]

This does not appear to be caused by the setup_ruby section in that image by itself, so does your project have an .rvmrc or any of the other files documented here that could be changing the configuration while in your cloned repository? The biggest difference at that point is that the Ruby image has rvm, and the NodeJS image does not.

[chris72205]

We have a .ruby-version and that's it. Our Gemfile specifies the version as well but they're all set to the same version as what's specified in the shippable.yml file.

One thing that I can't figure out though is if I remove the Postgres service and any reference to shipctl, then the build runs fine. It still doesn't pass because I need a database, but it errors out with an expected reason.

[chris72205]

Hey @a-murphy I was able to figure out the issue. It turned out being an incorrect nvm version but it wasn't obvious due to what I would consider a bug on Shippable's end. When running shippable_service postgres start it's calling a file named postgres.sh which starts off with the following code:

#!/bin/bash -e
# Begin service ENV variables
source "$(dirname "$0")/postgres_env.sh"
# End service ENV variables
service_cmd=$1

start_generic_service() {
...

The bug is on that first line with the -e flag which is burying other errors. When I removed that, I was finally greeted with an error complaining about the wrong nvm version. I didn't look at the other service files, but perhaps this will help with debugging the cause of #4642... since calling shipctl also resulted in the build failing for no apparent reason.