Build: netlify build is not working when @netlify/build is updated to 2.0.10

[Brew-Brew]

Describe the bug

netlify build is not working when @netlify/build is updated to 2.0.10
It works when version is 2.0.8
i made my project with cra

Deploy logs

7:55:46 AM: yarn run v1.17.0
7:55:46 AM: 
7:55:46 AM: $ react-scripts build
7:55:47 AM: Setting NODE_PATH to resolve modules absolutely has been deprecated in favor of setting baseUrl in jsconfig.json (or tsconfig.json if you are using TypeScript) and will be removed in a future major release of create-react-app.
7:55:47 AM: Creating an optimized production build...
7:56:00 AM: 
7:56:00 AM: Treating warnings as errors because process.env.CI = true.
7:56:00 AM: Most CI servers set it automatically.
7:56:00 AM: 
7:56:00 AM: Failed to compile.
7:56:00 AM: 
7:56:00 AM: ./src/pages/Home/index.jsx
7:56:00 AM:   Line 12:7:  img elements must have an alt prop, either with meaningful text, or an empty string for decorative images  jsx-a11y/alt-text
7:56:00 AM: ./src/App.js
7:56:00 AM:   Line 2:50:  'Link' is defined but never used  no-unused-vars
7:56:00 AM: ./src/pages/Result/index.jsx
7:56:00 AM:   Line 3:8:     'AdSense' is defined but never used                                                                        no-unused-vars
7:56:00 AM:   Line 90:11:   img elements must have an alt prop, either with meaningful text, or an empty string for decorative images  jsx-a11y/alt-text
7:56:00 AM:   Line 95:11:   img elements must have an alt prop, either with meaningful text, or an empty string for decorative images  jsx-a11y/alt-text
7:56:00 AM:   Line 107:13:  img elements must have an alt prop, either with meaningful text, or an empty string for decorative images  jsx-a11y/alt-text
7:56:00 AM:   Line 120:13:  img elements must have an alt prop, either with meaningful text, or an empty string for decorative images  jsx-a11y/alt-text
7:56:00 AM: 
7:56:00 AM: error Command failed with exit code 1.
7:56:00 AM: 
7:56:00 AM: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
7:56:01 AM: ​
7:56:01 AM: ┌─────────────────────────────┐
7:56:01 AM: │   "build.command" failed    │
7:56:01 AM: └─────────────────────────────┘
7:56:01 AM: ​
7:56:01 AM:   Error message
7:56:01 AM:   Command failed with exit code 1: yarn build
7:56:01 AM: ​
7:56:01 AM:   Error location
7:56:01 AM:   In Build command from settings:
7:56:01 AM:   yarn build
7:56:01 AM: ​
7:56:01 AM:   Resolved config
7:56:01 AM:   build:
7:56:01 AM:     command: yarn build
7:56:01 AM:     publish: /opt/build/repo/build
7:56:01 AM: Caching artifacts
7:56:01 AM: Started saving node modules
7:56:01 AM: Finished saving node modules
7:56:01 AM: Started saving build plugins
7:56:01 AM: Finished saving build plugins
7:56:01 AM: Started saving yarn cache
7:56:01 AM: Finished saving yarn cache
7:56:01 AM: Started saving pip cache
7:56:01 AM: Finished saving pip cache
7:56:01 AM: Started saving emacs cask dependencies
7:56:01 AM: Finished saving emacs cask dependencies
7:56:01 AM: Started saving maven dependencies
7:56:01 AM: Finished saving maven dependencies
7:56:01 AM: Started saving boot dependencies
7:56:01 AM: Finished saving boot dependencies
7:56:01 AM: Started saving go dependencies
7:56:01 AM: Finished saving go dependencies
7:56:04 AM: Error running command: Build script returned non-zero exit code: 1
7:56:04 AM: Failing build: Failed to build site
7:56:04 AM: Failed during stage 'building site': Build script returned non-zero exit code: 1
7:56:04 AM: Finished processing build request in 1m9.171072347s

[ehmicky]

Hi @Brew-Brew,

Thanks for reporting this.

I think this might have to do with the following problem (which is unrelated to @netlify/build 2.0.10, but happened at the same time): we are now setting the environment variable CI to true. This creates the following behavior in react-scripts:

7:56:00 AM: Treating warnings as errors because process.env.CI = true.
7:56:00 AM: Most CI servers set it automatically.

Some ways to fix this would be either:

• fixing the warnings that are printed on the console
• unsetting the CI environment variable when calling react-scripts. For example CI= react-scripts build inside your package.json

[Brew-Brew]

I fixed with CI= react-scripts build script! Thanks @ehmicky !

[grp06]

changing "build": "react-scripts build" to "build": "CI= react-scripts build" worked for me too. My site is also deployed to Netlify and mysteriously didn't build either.

Can you elaborate why this happened? Will anyone with create-react-app hosted on Netlify experience this? Will there be a fix that will allow me to revert this commit that fixes it?

I guess i don't quite get why this is closed?

[ehmicky]

create-react-app prints some warnings as part of the generated build command. Those warnings make the build fail in CI.

create-react-app is detecting CI environment using the CI environment variable. This environment variable is set by virtually all other continuous integration providers. Netlify was mistakenly not setting this, which was making all libraries with CI-specific behavior not behave correctly on Netlify. This problem got fixed few days.

In other words, the problem described above is not specific to Netlify, but to create-react-app. If the same application was hosted on any other CI provider, the same failure would occur.

Arguably, if create-react-app enforces making warnings a failure in CI, it means they intend developers to fix those warnings before they go to production. That being said, I do think there should ideally be some CLI flag with create-react-app to opt-out of that behavior, but unfortunately there is not.

[StevenCreates]

Why is this closed?

[StevenCreates]

The reason I ask is that I want to know if my update to adding CI= will need to be reverted if it gets fixed?

[Pieparker]

Hey @StevenCreates,

It depends what you mean by fixed. If you fix the warnings within the Netlify deploy log, you will not be required to add CI=.

If you do not wish to resolve your warnings, you'll need to add CI= indefinitely.

I appreciate that this is a breaking change which could have been communicated more effectively. However, the implementation of this is to ensure that our builds enforce a certain standard of CI behaviour.