bin/setup fails on circleci

[toobulkeh]

The bin/setup command is failing on CircleCI with the default format:

if heroku join --app app-staging > /dev/null 2>&1; then
  git remote add staging [email protected]:app-staging.git || true
  printf 'You are a collaborator on the "app-staging" Heroku app
'
else
  printf 'Ask for access to the "app-staging" Heroku app
'
fi

if heroku join --app app-production > /dev/null 2>&1; then
  git remote add production [email protected]:app-production.git || true
  printf 'You are a collaborator on the "app-production" Heroku app
'
else
  printf 'Ask for access to the "app-production" Heroku app
'
fi

Builds timeout on this line: if heroku join --app app-production > /dev/null 2>&1; then I'm working on this with CircleCI support, but noticed that this has changed recently with Suspenders.

[nickcharlton]

This is something we've seen in a few places and I wonder if the change to the Heroku command was fixing something which Heroku had changed?

I think what you're seeing is a prompt asking a question which is being redirected to /dev/null so you never see it.

I don't know of a better solution and this is something that seems to change now and again.

[toobulkeh]

Nope, so we're getting an actual Timeout on all of our CircleCI builds using that output redirect 2>&1.

I've replaced that with our old format, and it works:

if heroku join --app app-staging &> /dev/null; then
  git remote add staging [email protected]:app-staging.git || true
  printf 'You are a collaborator on the "app-staging" Heroku app\n'
else
  printf 'Ask for access to the "app-staging" Heroku app\n'
fi

[toobulkeh]

Here's the source of that sh construct change: https://github.com/thoughtbot/administrate/commit/f9777691f2e22ca33226a40900e347046673ba30

Note that I'm not too familiar with shell outputs and differences between shells (sh and bash in this case).

My guess is you'll see this failure if you build it on a brand new CircleCI setup and then it's cached from that point forward and never re-run, which is why it hasn't been caught. Or CircleCI changed something recently and it's breaking (this is our only project using this new convention)

[croaky]

I think the intent is for the Heroku-related commands to be wrapped in:

# Only if this isn't CI
if [ -z "$CI" ]; then
fi

[toobulkeh]

I always wondered why that was there...

But with the current circle.yml we do want to run these commands on CircleCI -- as it uses bin/setup and bin/deploy (which requires git remotes)

[mike-burns]

Looks like the PR should be around this: https://github.com/thoughtbot/suspenders/blob/master/lib/suspenders/adapters/heroku.rb#L8-L17 That should insert this instead:

if [ -z "$CI" ]; then
  #{command_to_join_heroku_app('staging')}
  #{command_to_join_heroku_app('production')}

  git config heroku.remote staging
fi

(And the commented-out CI checks in bin/setup can be removed.)

Thanks for finding this.

[toobulkeh]

If that's the case, how does the bin/deploy staging command work in circle.yml?

https://github.com/thoughtbot/suspenders/blob/675d2cee9118712b9bac7066ce989cfcba791cf4/spec/features/heroku_spec.rb#L48

We solved this overall issue by using the following in bin/setup:

if git remote add staging [email protected]:staging.git &> /dev/null; then
  printf 'Setup staging remote\n'
else
  printf 'Staging remote previously setup\n'
fi
          
if git remote add production [email protected]:production.git &> /dev/null; then
  printf 'Setup production remote\n'
else
  printf 'Production remote previously setup\n'
fi

git config heroku.remote staging

getting rid of the check for "Asking for permission" -- as that didn't seem to work locally anyways (I believe the output of the heroku command has changed over time, since it was originally written)