Different behaviour building with modules and dart-sass in Github Actions

Having a bit of a bizarre issue when attempting to build my site on Github using Github Actions. My site is comprised of a module with a theme that makes use of dart-sass and bulma.io, and the theme has a SCSS file that uses a @use declaration to bring in Bulma,

Locally everything works fine, on my main deployment host, everything works fine, but on GitHub actions it fails with:

Error: error building site: TOCSS-DART: failed to transform "/scss/base.scss" (text/x-scss): "/tmp/hugo_cache_runner/modules/filecache/modules/pkg/mod/github.com/2315-!media/2315-theme@v0.0.0-20240628100852-5b890913708d/assets/scss/base.scss:3:0": Can't find stylesheet to import.

The top of base.scss is the following:

@use "hugo:vars" as h;

@use "bulma" with (
    $primary: h.$primary_color,
    $link: h.$link_color,
    $navbar-height: 4.5rem,
    //$card-radius: 6px,

All the Bulma files are located in the assets/scss folder in a folder named bulma, I’ve added a post step to the workflow to run a find /tmp/hugo_cache_runner to confirm that the files are there and they are.

The workflow is a copy of the stock one, adjusted to use a Makefile

# Run tests on the website build
name: Test - Run a test build

      - "*"

# Default to bash
    shell: bash

  # Test job
    runs-on: ubuntu-latest
      HUGO_VERSION: 0.127.0
      GOPRIVATE: github.com/2315-Media/*
      GH_ACCESS_TOKEN: ${{ secrets.GH_ACCESS_TOKEN }}
      - name: Setup access for private go modules
        run: |
          git config --global url.https://$GH_ACCESS_TOKEN@github.com/.insteadOf https://github.com/    
      - name: Install Hugo CLI
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
          && sudo dpkg -i ${{ runner.temp }}/hugo.deb
      - name: Install Dart Sass
        run: sudo snap install dart-sass && sudo snap alias dart-sass sass
      - name: Checkout
        uses: actions/checkout@v4
          submodules: recursive
          fetch-depth: 0
      - name: Install Node.js dependencies
        run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true"
      - name: Build with Hugo
        run: make build

The makefile:

	sass --version
	HUGO_ENVIRONMENT=production HUGO_ENV=production hugo --gc --minify --cleanDestinationDir --logLevel INFO || find /tmp/hugo_cache_runner/

Before I attempt to create a demo repo (as its a private repo) with the issue, does anyone have any insight on to what could be causing this? I feel like using dart with modules seems to be a limited use case (from what I can see on the forums and google results) and I want to make sure I’m not missing something obvious.

I can reproduce the problem with this public project:

That loads this public module:

The public module transpiles Bulma to CSS using Dart Sass.

See error log:

Not sure why this is happening. Will investigate. Possibilities:

  1. Regression (seems unlikely)
  2. Security config (env vars)
  3. The snap package’s strict confinement

OK, the problem is #3. Change the workflow file:

      - name: Install Dart Sass
        run: |
          curl -LJO https://github.com/sass/dart-sass/releases/download/${DART_SASS_VERSION}/dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz \
          && tar -xf dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz \
          && cp -r dart-sass/* /usr/local/bin \
          && rm -rf dart-sass* \
          && sass --embedded --version

And add this bit:

      HUGO_VERSION: 0.128.0
      DART_SASS_VERSION: 1.77.5
1 Like

@nikdoof Please change the Dart Sass installation method as shown above and let me know the results. It’s working for me with a public project and public module:


@jmooring works perfectly with the private repo and private module combo.

So, on my dev system I install dart-sass by homebrew (macOS M1), and I think I did a binary install on our production CentOS Linux host rather than snap. Could it be something with the snap package?

Yes, the snap package is strictly confined, by design. I’ll update our example workflow file to no longer use that installation method.

Specifically, strictly confined snaps do not have access to the system /tmp directory, which is where the module is cached when building with GitHub Pages. Using the snap locally is not a problem because the module is cached within the user’s home profile (e.g., ~/.cache/hugo_cache).

1 Like

Ahh, so the command is called via snap, so it has access to base.scss only, and can’t see the rest of the files in the folder.

So potentially setting the cache folder to a different location under home would potentially work for using snap.


I’m not sure how I want to address this. Options:

  1. Add a plug to the snap to allow access to /tmp. This needs to go through a formal approval process, and there’s no guarantee it will be granted.
  2. Change our sample workflow as shown above
  3. Change our sample workflow to set HUGO_CACHEDIR

Looking into #1, this won’t be approved:

acceptance in the store requires that the interface is not be used to access system files where the snap is not the clear owner

And clearly the Dart Sass snap package is not the clear owner of /tmp.

1 Like

Addressed this with:


We continue to use the snap package, but with an accessible cache directory:

      - name: Build with Hugo
          HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
          HUGO_ENVIRONMENT: production
          TZ: America/Los_Angeles

This location also makes it a bit easier to use the cache action.

See also:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.