What command/process builds the included assets?

AI-generated summary

A discussion on what process builds included assets in Discourse. merefield asked about the creation of stylesheet assets during build and how to handle missing assets. david explained that stylesheets are built by the Rails app on-demand, but can be compiled eagerly using bin/rake assets:precompile. This is useful for creating an optimized Docker image.

When assets are compiled on-demand and stored on S3, they are not uploaded to S3. Instead, they are fetched directly from the application or via the CDN_URL. pfaffman noted that this explains why some assets are served by the application, and david added that these assets are cached in postgres/redis, allowing other containers to fetch the compiled version cheaply.

david also mentioned that if a CDN is configured, containers might not need to write assets to the filesystem. pfaffman is investigating an issue with some assets not loading properly and is seeking further explanation.

What process creates the stylesheet assets during build, e.g. /stylesheets/color_definitions_dark_1_1_603243e2b6c0b7xydx234the00538538bd705.css

I’m assuming this is the process of bundling?

What might be going wrong if these are missing?

Should these start to exist as part of starting ember-cli or the rails server?

What approach should I take to build these in docker from the standard discourse image or should I expect them to exist by simply launching the servers?

Stylesheets are built by the rails app on-demand, so in theory you don’t need to do anything manually.

Running bin/rake assets:precompile will compile them eagerly, which can be useful if you want to create an optimised docker image for rolling out to multiple hosts.

Thanks David that narrows down my investigation nicely

Aha! I’ve always wondered about that.

If they are on S3 and they get compiled on-demand, do they also get uploaded to S3?

Compiled-on-demand assets (e.g. stylesheets, theme-javascripts, svg-sprites) are not uploaded to S3. They are fetched directly from the application (or via the CDN_URL, if configured).

Static things like core/plugin JS and locales are generated by assets:precompile, and are guaranteed never to change at runtime.

I see; that helps explain why some stuff is served by the application. If there are multiple containers running (say, behind a load balancer), each of them will generate those on demand.

Yep, exactly. These things also tend to be cached in postgres/redis so they only need to be generated by the first app container to receive a request. The other containers can then cheaply fetch the compiled version from redis/postgres and write it to the filesystem.

And if there is a CDN, then they might not even need to, I guess.

I’m working with someone who seems to have an issue with some assets not loading (some icons are showing up really big) and I’m looking for some explanation.