"Must supply cloud_name in tag or in configuration" when precompiling assets #21

Closed
assembler opened this Issue Jul 3, 2012 · 18 comments

Comments

Projects
None yet
4 participants
@assembler
Contributor

assembler commented Jul 3, 2012

I was using cloudinary_url sass helper in my app:

background: #eac891 cloudinary_url('purty_wood.png', $format: 'jpg') repeat 0 0;

When I try to deploy the app to heroku, it fails to precomplie assets with following error:

Must supply cloud_name in tag or in configuration

https://github.com/cloudinary/cloudinary_gem/blob/master/lib/cloudinary/utils.rb#L71

@nadavs

This comment has been minimized.

Show comment
Hide comment
@nadavs

nadavs Jul 5, 2012

Collaborator

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?

Collaborator

nadavs commented Jul 5, 2012

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

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 5, 2012

Contributor

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
Contributor

assembler commented Jul 5, 2012

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

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 5, 2012

Contributor

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.

Contributor

assembler commented Jul 5, 2012

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

This comment has been minimized.

Show comment
Hide comment
@nadavs

nadavs Jul 5, 2012

Collaborator

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?

Collaborator

nadavs commented Jul 5, 2012

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

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 9, 2012

Contributor

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
Contributor

assembler commented Jul 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 9, 2012

Contributor

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

RACK_ENV                  => staging
RAILS_ENV                 => staging
Contributor

assembler commented Jul 9, 2012

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

RACK_ENV                  => staging
RAILS_ENV                 => staging
@nadavs

This comment has been minimized.

Show comment
Hide comment
@nadavs

nadavs Jul 9, 2012

Collaborator

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.

Collaborator

nadavs commented Jul 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 10, 2012

Contributor

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

Thanks @nadavs!

Contributor

assembler commented Jul 10, 2012

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

Thanks @nadavs!

@assembler assembler closed this Jul 10, 2012

@assembler assembler reopened this Jul 11, 2012

@assembler

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 11, 2012

Contributor

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

Contributor

assembler commented Jul 11, 2012

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

@assembler

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 11, 2012

Contributor

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

Contributor

assembler commented Jul 11, 2012

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

This comment has been minimized.

Show comment
Hide comment
@nadavs

nadavs Jul 12, 2012

Collaborator

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?

Collaborator

nadavs commented Jul 12, 2012

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

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 12, 2012

Contributor

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.

Contributor

assembler commented Jul 12, 2012

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

This comment has been minimized.

Show comment
Hide comment
@nadavs

nadavs Jul 12, 2012

Collaborator

.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!

Collaborator

nadavs commented Jul 12, 2012

.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

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 12, 2012

Contributor

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?

Contributor

assembler commented Jul 12, 2012

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

This comment has been minimized.

Show comment
Hide comment
@assembler

assembler Jul 12, 2012

Contributor

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

Contributor

assembler commented Jul 12, 2012

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

This comment has been minimized.

Show comment
Hide comment
@nadavs

nadavs Jul 18, 2012

Collaborator

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

Collaborator

nadavs commented Jul 18, 2012

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

@nadavs nadavs closed this Oct 28, 2012

@rubish

This comment has been minimized.

Show comment
Hide comment

rubish commented Mar 17, 2013

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

@itaibenari itaibenari referenced this issue in assembler/attachinary Feb 25, 2014

Closed

Staging ENV fails #80

@patrickespake

This comment has been minimized.

Show comment
Hide comment
@patrickespake

patrickespake Jun 14, 2014

+1 with Carrierwave and Cloudinary in Rails application.

+1 with Carrierwave and Cloudinary in Rails application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment