Bud errors not failing build

When running a yarn build on sage 10 with bud, css errors (inside scss files) result in builds still completing — which is allowing production deployments to go through with (with trellis’ default build-before.yml task) despite not completing the build successfully.

I’m hoping for some guidance or sample configs to both/either ensure that deployments don’t complete if the bud build results in errors — or ensure that those errors during build bubble up and result in the build actually “failing” (for lack of a better term perhaps).

I understand that sage 10 no longer comes with linting and offers some suggestions on getting that going, but these would seemingly be an additional/separate layer, not resulting in the “bud build” command failing despite the reported errors.

Any thoughts or conversation here would be appreciated. I know that I could always just make sure that I’m running a local build before deployments, but this was always a nice feature previously in the roots stack — deployments failing if the build process returned any errors.

Thanks in advance here for anyone with thoughts or insights.

This shouldn’t be the behavior that happens when there’s a failure in the build, but I’ve got lots of questions — we need more details in order to help.

Most importantly, what version of Bud?
What’s your Bud config?
What dependencies do you have? Including the versions
Where’s a code example that we can use to reproduce this error?

Provide us with all of the details to create a minimal reproducible example in this topic please.

1 Like

I’m happy to provide whatever you’d like and glad to hear that this isn’t expected behavior.

I can give you the the files and versions of the theme site I was working on if they end up being needed but for simplicity’s sake I just tried this with a fresh sage install and was able to replicate.

I took a brand new version of sage 10 and added an additional css file which I imported into app.css. I threw 1 generic style and built— no problems. I removed the closing curly bracket and rebuilt which returned errors as expected, but it left all the previous contents of the /public directory. The output of the failed build can be seen in the screenshots below, along with the contents of my public directory afterwards. You’ll see that the app.css file isn’t in the list of build assets from the failed build output, but there is still an app.css file in my public directory — only it has a different cache-busting string than the rest of the files because it was leftover from my previous (successful) build.

After a failed build, I commited these and triggered a deploy. The deploy went through successfully despite there being errors in the build and it not producing an app.css file at all, breaking the remote environment.

I think this should all be able to be replicated with out of the box sage/trellis installs as long as you introduce a breaking change to the compilation of your styles.

Let me know if you want me to provide anything more specific but I think you should hopefully be able to replicate this pretty easily.

Screen Shot 2023-01-05 at 11.22.55 AM

I’d start out by providing all of the things that I asked for… and no screenshots, please.

I’m asking for these specific details because just “the latest” is not going to be helpful if anyone needs to reference this topic in the future. Bud versions are also frequently changing.

Sure thing.

bud version:

Additional dependencies:

package.json contents

  "name": "sage",
  "private": true,
  "browserslist": [
    "extends @roots/browserslist-config"
  "engines": {
    "node": ">=16.0.0"
  "type": "module",
  "scripts": {
    "dev": "bud dev",
    "build": "bud build",
    "translate": "yarn translate:pot && yarn translate:update",
    "translate:pot": "wp i18n make-pot . ./resources/lang/sage.pot --include=\"app,resources\"",
    "translate:update": "for filename in ./resources/lang/*.po; do msgmerge -U $filename ./resources/lang/sage.pot; done; rm -f ./resources/lang/*.po~",
    "translate:compile": "yarn translate:mo && yarn translate:js",
    "translate:js": "wp i18n make-json ./resources/lang --pretty-print",
    "translate:mo": "wp i18n make-mo ./resources/lang ./resources/lang"
  "devDependencies": {
    "@roots/bud": "6.6.9",
    "@roots/bud-tailwindcss": "6.6.9",
    "@roots/sage": "6.6.9"
  "dependencies": {}

bud.config.js contents

 * Build configuration
 * @see {@link https://roots.io/docs/sage/ sage documentation}
 * @see {@link https://bud.js.org/guides/configure/ bud.js configuration guide}
 * @typedef {import('@roots/bud').Bud} Bud
 * @param {Bud} app
export default async (app) => {
   * Application entrypoints
   * @see {@link https://bud.js.org/docs/bud.entry/}
      app: ['@scripts/app', '@styles/app'],
      editor: ['@scripts/editor', '@styles/editor'],

     * Directory contents to be included in the compilation
     * @see {@link https://bud.js.org/docs/bud.assets/}

     * Matched files trigger a page reload when modified
     * @see {@link https://bud.js.org/docs/bud.watch/}
    .watch(['resources/views', 'app'])

     * Proxy origin (`WP_HOME`)
     * @see {@link https://bud.js.org/docs/bud.proxy/}

     * Development origin
     * @see {@link https://bud.js.org/docs/bud.serve/}

     * URI of the `public` directory
     * @see {@link https://bud.js.org/docs/bud.setPublicPath/}

     * Generate WordPress `theme.json`
     * @note This overwrites `theme.json` on every build.
     * @see {@link https://bud.js.org/extensions/sage/theme.json/}
     * @see {@link https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/}
      color: {
        custom: false,
        customDuotone: false,
        customGradient: false,
        defaultDuotone: false,
        defaultGradients: false,
        defaultPalette: false,
        duotone: [],
      custom: {
        spacing: {},
        typography: {
          'font-size': {},
          'line-height': {},
      spacing: {
        padding: true,
        units: ['px', '%', 'em', 'rem', 'vw', 'vh'],
      typography: {
        customFontSize: false,

1 Like

Thanks for the details, and thanks for bringing this to our attention

Reported here: [bug] Bud returns "0" exit code when the build errors · Issue #1986 · roots/bud · GitHub

This will be fixed in the next Bud release

Glad to hear it and happy to help. Keep up the good work and I’ll keep an eye out for the next bud release.

Do you happen to have any thoughts on the persisting of the /public directory when initiating a new build? I think it would make sense to destroy the existing public directory when starting the build process to ensure that there aren’t any artifacts from previous builds getting left behind and brought over.

That’s certainly less of a priority though and I’m open to hearing any thoughts/justifications behind leaving things as-is, but I feel like this might have been a separate but related issue leading to the results that I had.