Ignore Files/Folder From Being Watched

[noahschumacher]

Expected behavior

I want to exclude a folder and its contents from being watched by Scaffold. I only want to watch files in a specific folder (src/) so that when I make changes to files in this folder the app re-compiles but does NOT rebuild.

Actual behavior

I am attempting to use Scaffold for development with my React App. For on the fly development locally we can simply run npm install and then npm start. When a local file changes the app will recompile quite fast.

Our Dockerfile for Skaffold is below:

FROM node:15.4.0-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["npm", "start"]

I am ignoring node_modules in my .dockerignore but on RUN npm install we rebuild them in the image. This causes Scaffold to attempt to watch node_modules folder and all its contents. However due to the size of this folder I reach the limit on the number of files I can watch and get the following errors:
Error: ENOSPC: System limit for number of file watchers reached

While it might be possible to increase the number of files being watched (stackoverflow) it is not the ideal solution.

Information

• Skaffold version: v1.17.2
• Operating system: macOS Big Sur
• Contents of skaffold.yaml:

apiVersion: skaffold/v2beta10
kind: Config
build:
  local:
    push: false
  artifacts:
    - image: noah/app
      context: ../app
      docker:
        dockerfile: Dockerfile
      sync:
        infer:
          - "**/*.js"
          - "**/*.jsx"
          - "**/*.css"
          - "**/*.html"
deploy:
  kubectl:
    manifests:
      - minikube/webapp/app-deployment.yaml
      - minikube/webapp/app-cluster-ip.yaml

My repo containing my ReactApp is outside of my repo for my k8s configs and skaffold.yaml. This is why I set the context and specify the dockerfile.

My understanding is that the sync: has no effect on what is actually watched. Perhaps I am incorrect here. Any and all help is really appreciated. For now we are using a different Dockerfile that builds after installing leaving behind the node_modules but this does not allow for on the fly re-compiling.

[MarlonGamez]

hey @noahschumacher, thanks for opening up this issue. Skaffold is supposed to respect your .dockerignore file, but I think our logic that searches for that file may be flawed. Would you be able to tell me a little bit about your file structure and where your .dockerignore is relative to other files/directories like your Dockerfile and ../app?

[noahschumacher]

Hi @marlon-gamez thanks for the speedy reply. My file structure is as follows:

app/
  - Dockerfile
  - .dockerignore
  - node_modules/
  - src/
k8s_repo/
  - skaffold.yaml

I know that my .dockerignore file is working properly and ignoring the node_modules (not copying over) by inspecting the image contents with an ls -al. However since I am rebuilding the node_modules folder with the npm install command perhaps it is not being ignored by the file watcher? Potentially it is an issue with the context I am setting

[nkubala]

@noahschumacher thanks for the update. Skaffold is supposed to omit the contents of your .dockerignore from the files it monitors, but it seems like it isn't doing that so there might be a bug. can you share the contents of your .dockerignore file? I want to try and reproduce this - bonus points if you can provide a small repository we can clone to track it down 😄

[noahschumacher]

@nkubala the contents of my .dockerignore is just:

node_modules/

I will try and put together a quick repo for reproducibility but since this issue isn't blocking our current dev I might not get to it for a few days or so. If you are trying to reproduce perhaps using this package.json would help?

{
  "devDependencies": {
    "@babel/core": "^7.10.5",
    "@babel/plugin-transform-runtime": "^7.12.1",
    "@babel/preset-env": "^7.12.1",
    "@babel/preset-react": "^7.12.5",
    "@svgr/webpack": "^5.5.0",
    "@testing-library/jest-dom": "^5.11.5",
    "@testing-library/react": "^11.1.1",
    "@testing-library/user-event": "^12.2.0",
    "apollo-mocked-provider": "^5.0.0",
    "babel-jest": "^26.6.3",
    "babel-loader": "^8.1.0",
    "css-loader": "^4.3.0",
    "dotenv-webpack": "^6.0.0",
    "eslint": "^7.13.0",
    "eslint-config-airbnb": "^18.2.1",
    "eslint-config-prettier": "^6.15.0",
    "eslint-import-resolver-webpack": "^0.13.0",
    "eslint-plugin-import": "^2.22.1",
    "eslint-plugin-jest": "^24.1.3",
    "eslint-plugin-jsx-a11y": "^6.4.1",
    "eslint-plugin-prettier": "^3.1.4",
    "eslint-plugin-react": "^7.21.5",
    "eslint-plugin-react-hooks": "^4.2.0",
    "file-loader": "^6.0.0",
    "html-webpack-plugin": "^4.5.0",
    "identity-obj-proxy": "^3.0.0",
    "jest": "^26.6.3",
    "msw": "^0.26.0",
    "prettier": "2.1.2",
    "sass": "^1.28.0",
    "sass-loader": "^10.0.5",
    "style-loader": "^1.3.0",
    "url-loader": "^4.1.0",
    "video.js": "^7.8.4",
    "webpack": "^4.44.0",
    "webpack-cli": "^3.3.12",
    "webpack-dev-server": "^3.11.0",
    "webpack-merge": "^5.6.1",
    "whatwg-fetch": "^3.5.0"
  },
  "dependencies": {
    "@apollo/client": "^3.2.5",
    "@babel/plugin-proposal-class-properties": "^7.10.4",
    "@material-ui/core": "^4.11.0",
    "@material-ui/icons": "^4.9.1",
    "@material-ui/lab": "^4.0.0-alpha.57",
    "apollo-link": "^1.2.14",
    "apollo-link-context": "^1.0.20",
    "apollo-link-error": "^1.1.13",
    "apollo-link-http": "^1.5.17",
    "dayjs": "^1.9.6",
    "formik": "^2.2.3",
    "graphql": "^15.4.0",
    "js-cookie": "^2.2.1",
    "pubnub": "^4.29.10",
    "pubnub-react": "^2.0.0-rc.0",
    "react": "^16.13.1",
    "react-dom": "^16.13.1",
    "react-easy-crop": "^3.3.1",
    "react-loading-skeleton": "^2.1.1",
    "react-router-dom": "^5.2.0",
    "react-scrollable-feed": "git+https://github.com/dizco/react-scrollable-feed.git#a6e6ee46eed793c68c9cea1b63979eae2ecec279",
    "yup": "^0.29.3"
  }
}

[tejal29]

Thanks @noahschumacher for the package.json

[briandealwis]

@noahschumacher I can't find any reports of macOS ever emitting Error: ENOSPC: System limit for number of file watchers reached — this seems specific to Linux systems using inotify, and many people encounter it using react as you're describing. I think you're seeing this error from within your Docker container, which is not under Skaffold's control.

[tejal29]

Will try to reproduce this in this week.

[uncvrd]

Hi all - I would like to mention that I am encountering this issue as well with a NodeJS project. For what it's worth, I completely removed file sync from my skaffold.yaml and I still see a:

listing files: [...]: too many open files

As soon as my project starts running after the pods are deployed.

My build artifact looked like this:

    - image: graphql-image
      context: app/graphql/src
      docker:
        buildArgs:
          ENV: development
      sync:
        manual:
          - src: "api/**/*.ts"
            dest: .

For reference I added what my sync looked like above.... sync focuses on anything inside the api folder in an attempt to have it avoid the node_modules folder at the same directory level.

Directory structure:

Dockerfile (with a .dockerignore ignoring the node_modules)

FROM node:14 as builder

WORKDIR /workspace

COPY package.json ./
COPY prisma ./prisma

RUN npm install

# In an attempt to make sure I didn't copy over the node_modules from local
# I manually copied the required directories..
COPY api ./api
COPY assets ./assets
COPY tsconfig.json ./

ARG ENV=development
ENV NODE_ENV ${ENV}

CMD npm run ${NODE_ENV}

When I remove my node_modules from local environment, build and deploy using Skaffold, I no longer have any problems running the project.

[demisx]

Could this be related #6072?

[nkubala]

@noahschumacher are you running on an M1 mac? I think @demisx is right about this being related to #6072, which boils down to an issue with the way we're building darwin/arm64 binaries.

[francescortiz]

We are suffering this on a PC Linux machines. We have to delete the node_modules directories before starting skaffold or wait 3 minutes for it to fulfill the Listing files to watch.... Disabling the watchers only postpones the wait to a later stage. We tried skaffold 2.0.1 and kaffold 2.0.4. We tried to put in .dockerignore file **/node_modules, node_modules, no_modules/ and **/node_modules/. No effect at all. Only deleting node_modules makes it spin up fast.

[ericzzzzzzz]

@francescortiz the issue should be fixed in v2.1.0, could you try it ?

[francescortiz]

Indeed it is. Thank you!

[noahschumacher]

As @francescortiz mentioned this has been fixed in v2.1.0. Closing the issue :)