Caching tailwind build assets in CI

[searls]

I'm here with a simple question: "is it possible to cache the tailwind build in CI?" My brand new app's Tailwind 4 build is quite slow in GitHub Actions and I would like to find a way to avoid paying the piper on every build (actually, twice on every build).

I was just scrutinizing my build time in GitHub Actions and came across this:

$ bin/rails db:test:prepare test test:system
≈ tailwindcss v4.1.4

Done in 9s
Running 47 tests in a single process (parallelization threshold is 50)
Run options: --seed 32133

# Running:

...............................................

Finished in 6.400974s, 7.3426 runs/s, 36.0883 assertions/s.
47 runs, 231 assertions, 0 failures, 0 errors, 0 skips
≈ tailwindcss v4.1.4

Done in 8s
Running 1 tests in a single process (parallelization threshold is 50)
Run options: --seed 604
# Running:
Capybara starting Puma...
* Version 6.6.0, codename: Return to Forever
* Min threads: 0, max threads: 4
* Listening on http://127.0.0.1:39819/
.
Finished in 2.022590s, 0.4944 runs/s, 0.4944 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips

Because both rails test and rails test:system each precompile assets (something I feel like is a bug when the same process is invoking them), I'm getting hit with a particularly expensive compilation step of 9s and then another of 8s. So that's 17 seconds for a test suite that doesn't depend on styles. It stood out to me because locally each build takes on the order of 380ms.

I was thinking that build results might be cached someplace like tmp/cache, but it appears they aren't cached anywhere in development or test? @flavorjones could you shed any light on what my options might be?

[flavorjones]

@searls Thanks for asking this question.

Tailwind v4's build process does not, to my knowledge, provide any way of skipping the build or doing an incremental build based on cached files. You may want to ask upstream at tailwindlabs/tailwindcss, though.

I'm surprised that your build is taking 8s, though, and I think one thing to do here is try to figure out why that is. Can you run this command in your CI environment, which should give you a breakdown of where tailwind is spending its time:

DEBUG=1 bin/rails tailwindcss:build[verbose]

On this point:

both rails test and rails test:system each precompile assets (something I feel like is a bug when the same process is invoking them)

I tend to agree? This may have to do with how this gem enhances existing rake tasks, which is something that a) people have been unhappy about in the past, and b) seems harder than it should be to get right. It might be interesting to take a look at

tailwindcss-rails/lib/tasks/build.rake

Lines 33 to 39 in 3fbc5ca

	if Rake::Task.task_defined?("test:prepare")
	Rake::Task["test:prepare"].enhance(["tailwindcss:build"])
	elsif Rake::Task.task_defined?("spec:prepare")
	Rake::Task["spec:prepare"].enhance(["tailwindcss:build"])
	elsif Rake::Task.task_defined?("db:test:prepare")
	Rake::Task["db:test:prepare"].enhance(["tailwindcss:build"])
	end

and try to discern a better way to do it.

[searls]

I tend to agree? This may have to do with how this gem enhances existing rake tasks, which is something that a) people have been unhappy about in the past, and b) seems harder than it should be to get right. It might be interesting to take a look at

Yeah, I've had similar issues with trying to enhance rake tasks over the years and I'm not entirely sure the problem isn't that rails test and rails test:system both individually call test:prepare instead of having a normal rake dependency on it. This is probably for test isolation reasons (some DB prep in one test suite could def spoil things for the next).

Since that same risk doesn't really apply to Tailwind, I wonder if the task tailwindcss:build could set a global variable on first run within a process and skip subsequent invocations after the first. Or, to be extra safe, only do so when a particular flag is present like TAILWIND_SKIP_REDUNDANT_BUILD_TASKS