"Must supply cloud_name in tag or in configuration" when precompiling assets about cloudinary_gem

[nadavs]

Thank you for reporting this issue.
When using Heroku with a Cloudinary account that was created using the Heroku add-on, the configuration variables (e.g., cloud_name) are defined automatically. The CLOUDINARY_URL environment variable contains the required configuration.
You can manually define this variable for your Heroku existing application:

heroku config:add CLOUDINARY_URL=cloudinary://API_KEY:API_SECRET@CLOUD_NAME

Do you have a config initializer or a cloudinary.yml file? Maybe the asset precompiling process does not fully initializes the Rails application?

[assembler]

I have already set that ENV variable.. but it is not working.

I'm deploying on heroku without the actual "cloudinary addon", but with manual setup. Is the presence of addon required to make things work?

I have cloudinary.yml file.. it looks like this:

default: &default
  enhance_image_tag: true
  static_image_support: true
  cdn_subdomain: true
  secure_distribution: false
  private_cdn: false

staging:
  <<: *default

[assembler]

In addition, having something like this:

background: #eac891 image_url('purty_wood.png') repeat 50% 0;

Serves assets from cloudinary in development, but from /assets folder in production env.

[nadavs]

It seems that running 'rake assets:precompile' is using 'production' Rails environment in default (instead of development or staging).
Does your cloudinary.yml has a 'production' section?

[assembler]

I've added the production section in yml file and now it fails during push:

-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       rake aborted!
       Must supply cloud_name in tag or in configuration

[assembler]

Btw, my heroku app is in staging env. I have these two as my heroku env vars:

RACK_ENV                  => staging
RAILS_ENV                 => staging

[nadavs]

From Heroku's documentation: https://devcenter.heroku.com/articles/rails3x-asset-pipeline-cedar
"The most common cause of failures in assets:precompile is an app that relies on having its environment present to boot. Your app’s config vars are not present in the environment during slug compilation, so you should take steps to handle the nil case for config vars (and add-on resources) in your initializers."

You can specifically define the cloud_name parameter (only) either in a cloudinary.yml file or in a Rails initializer.

[assembler]

I added cloud_name parameter to cloudinary.yml in production section and now it works!

Thanks @nadavs!

[assembler]

Now it doesn't work again on heroku. It just fails silently and doesnt serve static assets from cloudinary

[assembler]

and in development, some of assets are served from cloudinary and some from local /assets folder even though all are synced and references in .cloudinary.static files are fine

[nadavs]

Hi Milovan,
It worked fine when we tried it. Can you please share some more details regarding the specific problem and environment so we can try finding the cause for the problem?

[assembler]

I have '.cloudinary.static' file ignored by git. After deploying to heroku I run: heroku run rake cloudinary:sync_static. It seems to be working, but I checked from console and it does not create .cloudinary.static file.

[nadavs]

.cloudinary.static should be included in your git repository (not listed in .gitignore).
We believe that the following happened: you deploy a version to Heroku which precompiles assets. While compiling sass files, .cloudinary.static is not available. Therefore, all URLs of images in generated CSS files are local asset files.
Running cloudinary:sync_static at Heroku would try uploading all images to Cloudinary. However, CSS files were already generated.
The way we planned it is that the developer runs cloudinary:sync_static in a local development environment and commits the generated .cloudinary.static file.

Please check if it works for you.
In addition, please tell us what do you think should be improved in this flow or its documentation. Thanks!

[assembler]

There are two things I don't like about this approach:

1. Developer needs to know API_KEY and API_SECRET for ALL environments (development, staging and production) in order to run that rake task. It is probably going to end up hard-coded into yml file and stored in repo which is a really bad thing.
2. If I run rake cloudinary:sync_static RAILS_ENV=staging and then rake cloudinary:sync_static RAILS_ENV=production, both of them are going to write to same file, and thus overwrite each other. I'd need to keep these files on different git branches and it is going to be complex and confusing.

I don't think we can even write to file (.cloudinary.static) from rake task on heroku. I think that heroku doesn't allow that..? When I run that task on heroku it kinda completes, but this File.exists? Rails.root.join(".cloudinary.static") returns false in heroku console.

Is there any way to have some kind of deploy hook that will sync static assets BEFORE precompiling assets?

[assembler]

If heroku could write to .cloudinary.static file would mean that if i run 2 successive deployments, second one would read from .cloudinary.static file and precompile assets correctly.. but it is not

[nadavs]

Thank you for sharing your thoughts about this approach.
Regarding your comments: the public IDs generated for uploaded static images include an MD5 hash based on the image's content. Therefore, you can run the sync_static command in any environment (development, staging, production). No conflicts or override problems should occur between environments even if they share the same image file names (whether the files are identical or different).
That's why we think it's easiest to run this command from your development environment and commit the .cloudinary.static file. You can set the API Key & Secret locally using the environment variable fetched form Heroku (heroku config -s).

Regarding writing to .cloudinary.static in Heroku: which Heroku stack do you use? In new stacks it should work: https://devcenter.heroku.com/articles/dynos#isolation_and_security

[rubish]

For any one else facing issues have a look at: https://devcenter.heroku.com/articles/labs-user-env-compile

[patrickespake]

+1 with Carrierwave and Cloudinary in Rails application.