Support working_directory

[fengxia41103]

Description:
Support working_directory value.

Justification:
I have a mono-repo project whereas folder structure is:

.
├── backend  <=== BACKEND
├── certbot
├── commit.template
├── docker-compose.dev.yml
├── docker-compose.dev.yml~
├── docker-compose.prod.yml
├── docker-compose.prod.yml~
├── docker-compose.yml -> docker-compose.dev.yml
├── docker-compose.yml~
├── docs
├── downloads
├── frontend   <==== FRONTEND
├── media
├── selenium
├── static
├── venv
└── waagent

To build frontend, I need to set working_directory to frontend, but use is not observing this value.

Are you willing to submit a PR?
No

[MaksimZhukov]

Hello @fengxia41103 !
Could you please explain your use case a bit more?
The action installs Node.js version, adds it to the PATH and optionally caches dependencies. You should use a separate step to build your project. You can specify working_directory in that separate step:

steps:
- uses: actions/checkout@v3

- uses: actions/setup-node@v3
  with:
    node-version: 16

- name: Install dependencies
  run: npm ci
  working-directory: ./frontend

- name: Build
  run: npm run build
  working-directory: ./frontend

[kevinawoo]

The error I'm getting is trying to use: see below

    - uses: actions/setup-node@v3
      with:
        node-version: '18.12.1'
        cache: 'npm'

is

Error: Dependencies lock file is not found in /runner/_work/repo-dir. Supported file patterns: package-lock.json,npm-shrinkwrap.json,yarn.lock

---

NVM! I realized cache: 'npm' in my usage was causing issues. Removing it resolved my issue.

[yandyestrada]

t looks like the error message is indicating that the lock file for the dependencies is not found in the specified directory. The supported lock file patterns are package-lock.json, npm-shrinkwrap.json, and yarn.lock.

However, it seems that you have identified the cause of the issue yourself. The cache: 'npm' parameter in the actions/setup-node step may be causing problems. Removing it may have resolved the issue.

If you still encounter issues, you could try running npm install or yarn install in your workflow to generate the lock file. Alternatively, you could specify the path to the lock file using the working-directory parameter in the actions/checkout step.

[siaikin]

I have the same issue and removing cache solves the problem. But this loses caching functionality.
I want to be able to set the path to lockfile so that projects with a "different" directory structure can use caching.

[darekkay]

I've encountered this issue after switching to the integrated caching in setup-node. The documentation includes the solution for this use case:

# Used to specify the path to a dependency file: package-lock.json, yarn.lock, etc. 
# It will generate hash from the target file for primary key. It works only If cache is specified.  
# Supports wildcards or a list of file names for caching multiple dependencies.
# Default: ''
cache-dependency-path: ''

Here's an example with Yarn and a <root>/app/yarn.lock file:

- uses: actions/setup-node@v3
  with:
    cache: "yarn"
    cache-dependency-path: "app"

And here's my working config file.

[asispts]

I can confirm that the solution proposed by @darekkay works as expected.

[JoseLion]

For monorepos, I think cache-dependency-path would rather be a workaround, not a real solution. The action should always honor the working-directory setting. IMO, that's the expected behavior on GitHub Actions.

Another property that has problems with this is node-version-file, even though you could specify the exact path to the file, having to do so is confusing when the working-directory path is already set:

defaults:
  run:
    working-directory: ./frontend

- uses: actions/setup-node@v3
  with:
    node-version-file: ./frontend/.nvmrc
    cache-dependency-path: ./frontend/yarn.lock
    cache: yarn

[molenick]

@darekkay's solution worked for me - maybe this could be improved by making the docs a bit clearer?

I searched for directory, working directory, etc but it wasn't clear to me there was an option to tweak this. Based on my googlin' and this issue, it seems like a lot of people are led down the path of "oh, I'll just do this and set my working-directory" to no avail.

[alundiak]

I also confirm this weird issue with actions/setup-node@v3 vs working-directory happed to me.

I rely on basic GitHub Actions template for NodeJS build and test, which always works OK. But this time my code was in sub-directory. What can be easier, right?

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    
    defaults:
      run:
        working-directory: ./docker-test-containers/

    strategy:
      matrix:
        node-version: [19.x, 20.x, 21.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}

      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        # cache: 'npm' # commenting SOLVED MY issue and build was OK
    - run: |
        npm ci
        npm test

I know, caching is important. But who would believe that simple matter of changing working directory would cause a build to fail.

So how to run this WITH caching then?

Adding cache back and ADDITIONALLY cache-dependency-path also helped:

cache: 'npm'
cache-dependency-path: './docker-test-containers/'

Output from logs:

Run actions/setup-node@v3
  with:
    node-version: 19.x
    cache: npm
    cache-dependency-path: ./docker-test-containers/
    always-auth: false
    check-latest: false
    token: ***

So, cache-dependency-path matters :)

Although, still don't get why cache-dependency-path isn't equal by default value of working-directory (if that provided)...