Heroku setup with Discourse has been simplified a lot over the development of Discourse (from what I can tell), but at the moment there is a hangup during asset compilation when the database has not been set up.
Is it possible to allow asset compilation when the DB hasn’t been created at all? I see that other assets fail ‘smoothly’, but compilation fails and exits when the color_schemes table hasn’t been created. Is there an easy workaround for this?
Otherwise, it seems like I can temporarily disable color schemes, but I’m not sure how. For now, I’ve been able to get past this by manually changing a few lines in discourse_sass_importer.rb (and now discourse_stylesheets.rb), which is definitely a hack.
Heroku doesn’t run migrations for you, so you have to push to Heroku first and then run migrations. However, Heroku will reject your deployment if asset compilation fails, so you get ‘stuck’.
For others in this situation, I was able to get around it with a few changes. In line 51 of discourse_sass_importer I skip the ColorScheme.enabled check:
# OVERRIDE FOR HEROKU COMPILATION
if color_scheme = false#ColorScheme.enabled
ColorScheme.base_colors.each do |name, base_hex|
override = color_scheme.colors_by_name[name]
contents << "$#{name}: ##{override ? override.hex : base_hex} !default;\n"
end
else
special_imports[name].each do |css_file|
contents << File.read(css_file)
end
end
I would love to have a SiteSetting to disable ColorScheme without checking the DB. That would still feel hacky, as I don’t really want to disable ColorScheme, I just want it to fail silently.
I’d be enthusiastic about contributing code for this solution if it’s agreed that it is a good idea.
Thing is, for Discourse to work correctly we need access to the DB when compiling assets, a lot of CSS can be customised based on data in the database.
We really need a way to communicate this to Heroku deployment system.
For the css at least, I made a change that skips the precompile if the table doesn’t exist. It can be compiled at runtime during the first request, so it’s safe enough. If there are future dependencies on tables, it will probably break again. Let’s hope that Heroku can change the way this is done.