Make it working on Heroku about bigtuna

[mattbeedle]

+1

[knoopx]

did you tried it? it don't see why it should not work (apart from file-based compiled haml templates)

[michalbugno]

We are on it and it looks like it will work, couple of projects were built properly, we will update as soon as we figure everything out.

Please note, that delayed job workers are billable by heroku starting from 1 instance. This means that the delayed job backend won't be free; one solution would be to give the ability to change delayed job to threaded worker, like integrity did.

[treybean]

Any way you can outline how you did it? Is there a fork or branch with the necessary changes?

[wuputah]

I am working on this as well - might end up duplicating some of the work you did, but oh well, I guess. I will be pushing up a branch on my fork when I have it working. Will update this as things progress.

[wuputah]

I had a version of BigTuna on Heroku working with private keys which was quite tricky to do, but Heroku has changed their setup so now ssh(1) does not function, meaning private keys on Heroku is a no-go for now, at least until I can code up something to use Net::SSH in its place (or Heroku fixes ssh(1)). This means you must use https://username:[email protected]/user/project.git syntax for all checkouts on Heroku, assuming you are trying to do CI git private projects.

The steps to get BigTuna to work on Heroku are:

• Change the Gemfile to use the pg gem instead of sqlite.
• Change the build directory to tmp/builds/
• Fix references to Rails.root in an expanded build path, since on Heroku, the path changes between execution of app and worker (use Dir.pwd instead, and delay any evaluation of this path to when we're inside the worker)
• Fix any permission issues with trying to mkdir_p the full path to the build directory (only mkdir_p a relative path?)

There are normal environment variable issues in build steps, depending on what you are trying to CI. For instance, you may need to set RAILS_ENV, BUNDLE_GEMFILE, and BUNDLE_WITHOUT appropriately. Add env as a build step to check the environment that Heroku + BigTuna provides you so you can adjust accordingly.

I will still be working to provide better support for Heroku out of the box - the first of which is to finish my build path ticket - but figured I would outline the current state here for others who are interested.

[avocade]

+1 also for "give the ability to change delayed job to threaded worker, like integrity did"
EDIT: @wuputah, agreed. This didn't work at all on heroku.

[wuputah]

Sorry, no intent to switch off a proper queue system. "Threaded workers" - which is really forked workers - sound great until they don't function properly. They also are not supported by Heroku - forking and using multiple children to do any simultaneously work is a violation of the Heroku TOS and will get your app killed.

[wuputah]

I have a fork up at https://github.com/wegowise/bigtuna/commits/heroku , but it is definitely not ready to be merged in.

[kerrizor]

Thanks for the work on this, guys.

[cldwalker]

I've started on a cedar branch, https://github.com/wegowise/bigtuna/tree/cedar. Will pull request when ready