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
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 recently added the dokku-shoreman plugin and a Procfile so that my app runs both a worker and web process when I deploy. It looks like this:
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
However, now I when I use dokku run <app> <cmd> such as ...rake db:migrate a server and worker start running instead.
Currently the only way I know how to run the worker is with the Procfile. It's not a big issue to start it manually after I deploy - only I don't know how.
Though the ideal would still be to have the both the Procfile and dokku run working.
Update 2 Dokku now supports this http://dokku.viewdocs.io/dokku/deployment/process-management/
Update: checkout dokku-alt (no longer maintained) first - it's what I've switched to instead.
This is a known issue with dokku.
This was a temporary solution detailed in the issue discussion that worked for me:
rename actualProcfile to Procfile.real
create a new Procfile with the following content:
web: bundle exec foreman start -f Procfile.real
add gem 'foreman' as a dep in Gemfile
run bundle install
commit Procfile* and Gemfile*
push
Whenever I run heroku run bundle exec sidekiq, I see all my background jobs being done, however, I want them to be able to go without me needing to be there. When I exit out of that terminal tab, sidekiq stops working. How would I mitigate that?
Also, I've read something about procfiles and increasing workers. I don't know what procfiles are and I don't know how to increase workers either.
Basically, I'm a newbie trying to get sidekiq set up to run on Heroku for my Rails app. I want it to be running at all times.
Create a file named ./Procfile with the following in it:
web: bundle exec rails server -p $PORT
worker: bundle exec sidekiq
sidekiq on Heroku
more on Procfiles
foreman gem
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.