I am having a problem with Heroku CI on a rails application. I just upgraded to Rails 7.0.1
Previous version was Rails 6.1.4.4
# Ferrum::TimeoutError:
# Timed out waiting for response. It's possible that this happened because something took a very long time (for example a page load was slow). If so, setting the :timeout option to a higher value might help.
This is how my Procfile looks like
web: bundle exec puma -C config/puma.rb
release: bundle exec rails db:migrate
Probably you're receiving this error because the :timeout parameter is missing in the Dynos. Try to create a Procfile and pas a :timeout var.
You can find some more useful help right here: https://devcenter.heroku.com/articles/request-timeout
Related
I'm trying to deploy my app on railway.app with Redis (using Sidekiq).
I'm using buildpacks and the problem is I have 2 buildpacks and railway says in its documentation only one buildpack is executed in the Procfile.
This is my Procfile:
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq
How could I execute both processes?
From the railway documentation:
All you need to do is connect your GitHub account, create a new project, and then deploy your repo. We even support Procfiles out of the box. (Caveat: only a single process is supported for now) [0]
[0] - https://docs.railway.app/reference/compare-to-heroku#moving-from-heroku-to-railway
Looks like you would need multiple "projects" to invoke extra processes.
I use the shopify_app gem to add webhooks to my app.
They work as expected in my local environment, but when I use the app from my Heroku environment, nothing happens when I do actions that should trigger the webhooks, nor is there any errors or anything at all in the logs.
Any ideas for how I should proceed to determine what the error is?
Update c.f. Davids comment (thanks for the input David):
I've added a call to the API to see which webhooks are installed for the app, and I can see the webhooks have not been succesfully installed - I will dig into this.
My procfile for Heroku has the following content:
web: bundle exec rails s
webpacker: ruby bin/webpack-dev-server
inventoryworker: bundle exec sidekiq -q default -q urgent -c 3
clock: bundle exec clockwork scheduler.rb
The Heroku setup is as follows:
one dyno for "web bundle exec rails s"
one dyno for "clock bundle exec clockwork scheduler.rb"
one dyno for "inventoryworker bundle exec sidekiq -q default -q urgent -c 3"
one off dyno for "webpacker ruby bin/webpack-dev-server"
I am expecting the webhooks to be handled by inventoryworker?
Thanks,
-Louise
Heroku logs. When you install the App, examine the logs. You'll see the webhooks be created or not. Ensure you setup Heroku correctly too. If you forgot a worker process, your webhook job won't run. Lots of little things to check.
Thanks to Davids hints I found out that the webhooks were not installed.
Looking at the logs during install I saw that the installation of webhooks works by adding a job to a queue - this queue name was not included in my configuration of starting sidekiq and for this reasonn webhooks were not installed.
Thanks,
-Louise
Having followed the rails-cast (http://railscasts.com/episodes/271-resque?view=comments), I was able to setup my rails application similarly with worker and rake tasks.
However, as specified in the rails-cast, once I start my rails server, I have to issue the following command in a separate terminal window:
TERM_CHILD=1 QUEUES=* rake resque:work
This gets me up-and-running and I have no issues. However, instead of firing off a rake command on terminal (or writing a startup shell script), I would like to issue this terminal command (TERM_CHILD=1 QUEUES=* rake resque:work) from Rails itself when the application starts up so its available during the duration of the application's uptime on the server.
I am in the process of learning Rails framework so I would greatly appreciate if you can give me some help and let me know how/where to place any code snippet you may provide me with.
Thank you very much in advance.
Here are my environment specs:
I am using jruby (jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_72-b14 +jit [linux-amd64])
Rails version 4.1.8
I am developing on LINUX ubuntu 14.04
I will be deploying this application to Windows 2008 server on a Tomcat server as a WAR package
I am using PostgreSQL as my database.
That approach would make it difficult to turn off your resque workers. I recommend using a common gem called foreman to handle this. I'll let you look a the documentation, but your Procfile would look something like:
web: rails s -p $PORT
resque: TERM_CHILD=1 QUEUES=* rake resque:work
And you would be able to start both rails and resque by just running the foreman command in console. That will also allow you to exit out of both easily.
Updated per OP's message:
require 'resque/tasks'
ENV['TERM_CHILD'] = 1
ENV['QUEUES'] = '*'
Thread.new { Rake::Task["resque:work"] }
The Thread.new is there because it would otherwise cause the rest of the app to never load.
New to Rails and very new to Delayed Jobs.
Got one that's supposed to be triggered after 5 minutes. I finally got it to work so that if I run
rake jobs:work
in my terminal, the job starts up and works correctly. If I CTRL-C and exit that action in my terminal, the delayed job stops working correctly. This is one thing on my local server and another on Heroku, where I have to start up the delayed job using
heroku run rake jobs:work
I looked into the new Heroku toolbelt and downloaded the gem they suggest for worker maintenance, foreman, but when I run "foreman start", I get this error
ERROR: procfile does not exist
I don't know what a procfile is, I'm afraid of breaking things after spending pretty much a day debugging my delayed_jobs actions, and I want to do this right to make sure it works instead of figuring out some hacky fix that breaks down later -- so I figured I should ask this question, however obnoxiously vague it may be.
Should I be using foreman for this? Or workless? (Saw that in another SO question). Where's my procfile? Should I do anything with it?
Thanks,
Sasha
You should be using a procfile to set up your Heroku processes, this is the standard method that Heroku uses to define and control the processes.
If you haven't utilised a procfile to this point everything will probably still work as Heroku adds some default processes when you push a Rails app, including both the web and worker processes. The default worker process is set to delayed job.
Foreman was developed in order to set up your local machine to use the same approach but, unlike the Heroku service, Foreman actually requires a procfile to be present to control the services that are started when Foreman is started as it doesn't know how to setup defaults.
I would suggest creating a procfile, placed in the root directory of your project, to ensure that your processes are set up and operating in the same manner on your local machine as on Heroku. If you want to mimic what Heroku sets up automatically you add the following to the procfile depending on whether you are using the Thin web server (which Heroku recommends) or not.
With Thin in your gemfile:
web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT
worker: bundle exec rake jobs:work
Without a special web server (eg you are using webrick, the rails default):
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
Once this file is in place you can run foreman on your local machine and it will start your web server and delayed_job workers automatically.
Running through this process will only impact starting delayed_job on the local machine. As you are running the exact same command bundle exec rake jobs:work as you are currently using there should be no impact on your dj actions in either locally or on Heroku. Obviously some testing is required to make suer this is actually the case.
Workless is designed to scale workers on Heroku so that you don't have to pay for them when there is no work available. It has no bearing on the procfile or defining how to actually start a dj worker process.
as far as I know, there are 2 version of delayed_job:
original(tobi's) https://github.com/tobi/delayed_job
collectiveidea's fork: https://github.com/collectiveidea/delayed_job
when using the collectiveidea version, you should start it as below:
# Runs two workers in separate processes.
$ RAILS_ENV=production script/delayed_job -n 2 start
I am not familiar with delayed_job on Heroku, please follow its instructions.
Here's what my Procfile looks like:
web: bundle exec rails server thin -p $PORT -e $RACK_ENV
worker: bundle exec rake jobs:work
I intend to add a worker process because I wish to run some background jobs. I'm following these instructions
This is what I noticed:
No problems encountered if the worker is started separately.
When I keep the second line in the Procfile and don't not change anything else, the rails server serves a couple of requests and hangs after that
As mentioned here , I've added STDOUT.sync = true to config/environments/development.rb and verified the same in the rails console. Did not work.
Tailed log/development.log and compared it against the stuff that foreman outputted to the shell and noticed that both matched for a couple of requests and then foreman stopped printing out stuff to the shell - the next request would then hang
I updated foreman using foreman.pkg as mentioned here and verified the same with [6]
It was mentioned here that this might be caused due to a stray debug statement. I'm not using the debugger and I do not have the pry gem or the ruby-debug gem in my Gemfile.lock
I believe the symptoms are similar to this related unanswered question
Please help!
[6]:
which foreman
/usr/bin/foreman
ls -lah /usr/bin/foreman # checked the updated date
Tracked and resolved here:
https://github.com/ddollar/foreman/issues/244
TL;DR: Install the gem, don't use foreman.pkg
I'll add than if you're using Heroku, the foreman version included with the heroku toolbelt has the same issue.
Use the one you can get with gem install foreman instead.