Ruby 2.7.0 - Warning: Using the last argument as keyword parameters is deprecated
Oliver Curting•
I've created a new Jumpstart Pro app (ruby 2.7.0, rails 6.0.0) and I'm getting warnings whenever I run a rails command. They always follow the format:
".../rvm/ruby-2.7.0/gems/{gem]-6.0.2.1/... warning: The called method '...' is defined here" OR "... warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call".
Warning when running foreman start
It is annoying but not breaking locally, but when I try to deploy to heroku it aborts rake:
Heroku deploy
What should I do?
Oliver Curting•
Edit: I realise this is the general behavior of ruby 2.7.0. But is it supposed to fail my build for Heroku? Because that's a severe show stopper.
Chris Oliver•
Oliver Curting
The error you have is ActiveSupport::MessageEncryptor::InvalidMessage. Nothing to do with Ruby 2.7 warnings.
You're just missing the RAILS_MASTER_KEY env var on Heroku.
Matt Bjornson•
Chris Oliver
I'm getting the same error and figured it was due to the RAILS_MASTER_KEY, I'm deploying to Digital Ocean and haven't figured this out yet. Do I take the value in conf/credentials/production.key and add that to the top of the file resulting from ``` EDITOR="vim" bin/rails credentials:edit --environment production``` ? Or am I missing something else?
Chris Oliver•
You take the contents of config/credentials/production.key and add it as an env var to Heroku, Hatchbox.io, or wherever you're hosting your app as RAILS_MASTER_KEY.
Since production.key is not stored in Git, you have to use an env var so your Rails app can decrypt the credentials file in production. If you stored the key in git, then anyone with access to the code could decrypt and it'd be kind of useless so it must be stored outside git.
Matt Bjornson•
Thanks Chris, I did that per your instructions on deploying where I used .rbenv-vars to store them, but I'm still getting the following errors and the deploy is failing... ``` DEBUG [da1c4454] rake aborted!
DEBUG [da1c4454] (See full trace by running task with --trace) ``` At the command line if I do ``` rbenv vars``` I see two outputs,
``` deploy@ubuntu-:~$ rbenv vars # /home/deploy/.rbenv-vars export RAILS_MASTER_KEY='what I see here is the same in production.key' export CRISPY_SNIFFLE_DATABASE_PASSWORD='(the pwd I setup for this user in pg)' ``` It's failing on the convertkey key/secret and I've confirmed both of those as well....
Chris Oliver•
Sounds like you missed something then since it is saying it can't decrypt which means the key is invalid.
Make sure you can see the ENV["RAILS_MASTER_KEY"] in irb. You can also run rails credentials:edit --environment=production on your server with the env set to verify you added it correctly.
Another option is to upload the production.key file to your server and symlink it every deploy, but most people use env vars.
Matt Bjornson•
Yeah there's something weird that is happening... I'm starting my local app in production and am not seeing the same errors that I am on Digital Ocean. I don't see any changes in my local repo from git... This tells me its something in my droplet config. I used your directions https://gorails.com/deploy/ubuntu/18.04 to set everything up. I can see the RAILS_MASTER_KEY in irb... In my last cap deploy I'm getting a slightly different error now,
I deleted the production.yml.enc file and everything started working just fine when I added my keys and secrets ( for convertkit, stripe, etc) to the global credentials. What I believe happened is that I didn't understand too well the credentials changes that happened in Rails 5.2 ( the gorails video on the topic was the best source I could find that explained the topic). I think at some point I tried switching out the secret_base_key for the master_key in production.yml.enc, but deleting that and putting that keys/secrets in the global, production environment worked fine.
Thanks
Chris Oliver
!
Oliver Curting•
Thank you very much. Everything worked out! :-) I had a wrong RAILS_MASTER_KEY and
Jim Jones
link on how to suppress them helped as well.
Matt Bjornson•
I seem to have messed up all my keys and secrets.... I just updated my jumpstart config to include using mailjet, and as I was saving, I noticed this in the console, ``` conflict config/credentials/production.key 19:18:31 web.1 | Overwrite /Users/matt/crispy-sniffle/config/credentials/production.key? (enter "h" for help) [Ynaqdhm] Started GET "/contacts" for ::1 at 2020-02-12 19:18:31 -0600 ``` Not knowing what I should do I pressed y and now I have a new master.key and a production.key.... I didn't notice the master.key before, which should I use in my ENV for RAILS_MASTER_KEY? Makes sense I should use the output of master.key, is that correct? Or should I use my production.key as my RAILS_MASTER_KEY? (note: after this process the production.key is now different, should it be?)
Chris Oliver•
Matt Bjornson
If you have a config/credentials.yml.enc and config/master.key, then you ran rails credentials:edit without the --environment=production option on accident. It's fine to use that, but I wouldn't recommend it. You should probably delete those files and use the environment credentials instead.
RAILS_MASTER_KEY should always be set to the matching environment .key file. If you're deploying a production instance, production.key. For staging, staging.key.
Matt Bjornson•
Thanks
Chris Oliver
that clears things up for me, much appreciated!
