Styles and scripts are not deployed to the server with Ansible


I’ve noticed that the directory where styles and scripts are normally compiled on my local VM, e.i. themes/sage/dist is not checked to the git directory (I’m using the default .gitignore that comes with Sage)

Consequently, the styles and scripts are not deployed to the serve when deploying with Ansible. The site is broken. CSS and JS files return a 404 error when inspecting with Chrome network tab.

This is very puzzling because I do not see any rule in the .gitignore that would tell Git to ignore this directory.

I thought that maybe the intention is that scripts and styles should be automatically re-built with Gulp on the server after each deploy. However, no such rebuilding takes place by default.

Why is the themes/sage/dist directory not deployed to the server? And how can I re-build my assets after a deploy?

Are you using Bedrock with bedrock-ansible? I assume so but you might be using Capistrano as well…

If it’s bedrock-ansible, running gulp is not built in by default as it’s not assumed you’ll be using a Sage theme. However it’s pretty easy to set this up to compile locally and upload to the server:

1 Like

Hi @kalenjohnson,

Yes, I’m using bedrock-ansible.

I might have it wrong, but the problem isn’t compiling assets locally, as I’m doing it manually with gulp. The problem is that the folder with compiled assets is never deployed to the server. Also, the project_local_files: seem to be just coping the whole local theme directory to the remote server. This is rather redundant since the deploy process uses a remote git repository.

Should I rather just manually run gulp --production on a remote server after each deploy to get the assets working?

Or maybe it’s better to just have a post-deploy command that would run gulp to generate the assets?

Line 19-21 of the Github link in my last post is supposed to take care of uploading the compiled theme files to the server during deploy.

The great thing about those options/settings mentioned by @kalenjohnson is that you can adjust them however serves you best. However, I think those options may have been closer to what you want than you realized.

You’ll notice that it isn’t syncing up the whole theme, just the compiled assets, i.e. the dist folder, which it drops in your theme folder that is already there after having cloned your repo. Typically, the repo you cloned wouldn’t already have the dist folder, at least if you take the approach that your source control doesn’t include compiled assets like dist, only source files.

You don’t have to have the deploy run gulp --production locally for you, but you might find it convenient to always have it compile the latest dist files for you before syncing them up.

1 Like

Thanks guys. Now I see that it all makes perfect sense. I managed to deploy successfully to the target server with the commands mentioned by @kalenjohnson.

However, after the deploy command run project_pre_build_commands_local, where assets were compiled for production, all is well on the remote server, but unfortunately, my local copy suffered.

For example, my local site is looking for dist/main.css while after running gulp --production the asset has a suffix, e.g. main-34h4dsf53.css. Consequently, I’m getting 404 on main.css. This is not the case on the remote server where correct, suffixed assets are loaded.

Why is that and what should I do to remedy the problem? Would really appreciate your help.


Just run gulp again or apply this commit to your theme:


All sorted, Thank you!

i tried this today, and i had to add a “dest” parameter to project_local_files:

 - name: compiled theme assets
   src: "{{ project.local_path }}/web/app/themes/sage/dist"
   dest: "web/app/themes/sage"

to get this to work

1 Like

I added this to trellis/group_vars/production/wordpress_sites.yml

However I get an error when trying to deploy. Do these options/settings still work?

That’s quite old now.

Here’s the newer method:

More docs here:

Thank you somehow I glazed over this in the docs.

Just bumping this old conversation out of curiosity … why is build-before.yml commented out by default? Is it because it’s only applicable if Sage is the theme being used?

Sort of, Sage/Bedrock/Trellis are great together but can also work independently without the others and so having it commented out by default means you can use Trellis with a different theme (that might not use gulp for the build process) by just configuring the settings, instead of having to find and remove unnecessary code.

Even if you are using the full Sage/Bedrock/Trellis stack you’ll probably want to rename Sage and so that file would need editing anyway.

It’s also because there are many ways of doing this, and this is just the simplest method.

Austin has a good post on this:

(the build-before hook is option #1)