Users are discussing a deployment issue on Heroku where asset compilation fails because the color_schemes table doesn’t exist yet, blocking deployment before migrations can run. hstove notes that Heroku rejects deploys if assets fail to compile, creating a catch-22. They share a workaround: modifying discourse_sass_importer to skip ColorScheme.enabled checks during compilation hstove. neil and sam clarify that Discourse normally requires DB access during asset compilation because CSS can be customized via the database. neil later proposes a fix: skipping precompilation if the color_schemes table is missing, deferring CSS compilation to the first runtime request — a safer approach for Heroku. hone confirms this works after pushing and running migrations. The core issue is the tight coupling between asset compilation and database state, which needs loosening for platforms like Heroku that separate deployment from migration.
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.