New CI=true build configuration, "Treating warnings as errors because process.env.CI = true"

Features Updates
,
1

Beginning on June 15, 2020 Netlify will start a gradual rollout of adding the environment variable CI to build environments, with the value of true . This environment variable, short for Continuous Integration, is commonly set in various CI environments like Travis CI and Github Actions, among many others. The ecosystem has largely agreed to use this environment setting to detect when a build is executing in a CI environment, as opposed to a local development environment.

This setting allows many common libraries to detect a CI environment and change behavior accordingly. One such behavior is the disabling of progress “spinners” that while useful in a local development terminal, can render poorly when operating in a log streamed CI environment.

However, one concern is that some libraries may now interpret what were previously just warnings as hard errors that will halt a build. The intention is that developers should not ship potentially broken configurations, but the downside is that builds that successfully completed previously may fail after this change. If you believe that your build is breaking after this change, you can disable this behavior by unsetting the CI variable in your build. For example, the following will unset CI for the NPM command:

CI= npm run build

If you would like to test this behavior in your build environment ahead of June 15th, you can explicitly set the CI variable in your build or explicitly for an individual command like:

CI=true npm run build

Update (from comment below):

Just a few clarifications on how to disable this. If your build command is npm run build , then you can disable it by setting a custom build command in the UI under your site’s Build Settings to:

CI= npm run build

or if you are using netlify.toml to set the build command, update it as such:

...
  command = "CI= npm run build"
...

Either option should work. You should see this build command reflected in the build output as well.

There is one more way to affect this behavior: you could instead choose to set the environment variable CI to empty in either the toml’s [build] section(s) or in our UI, in the Deploy Settings → Environment variables configuration section of our UI.

Let us know if you have any questions in the thread below!

6 Likes
2

Just a reminder that we are starting to roll this out today.

3 Likes
4

I should start paying attention to netlify marketing emails :frowning:

Lost 30 mins to find out whats wrong.

1 Like
5

At least you found us now; that’s the important bit!

2 Likes
6

I added CI= to my build command and it’s still failing

2 Likes
7

I’ve tried running CI= npm run build on the command line and it’s still failing for me when trying to deploy to production.

8

Hi,

Just a few clarifications on how to disable this. If your build command is npm run build, then you can disable it by setting a custom build command in the UI under your site’s Build Settings to:

CI= npm run build

or if you are using netlify.toml to set the build command, update it as such:

...
  command = "CI= npm run build"
...

Either option should work. You should see this build command reflected in the build output as well.

Cheers,
Mike

1 Like
9

@mheffner this broke about a dozen projects. we don’t pay you to break our stuff.

2 Likes
10

hi @jacobs, were you able to remediate issues with building given the steps outlined above? If not, please do let us know so we can assist.

11

No. I set an environment variable for CI to false, but that does not do it. This would have been a fairly quick fix. If I have to go and change the build command for all of our projects, I will absolutely be demanding a refund for my time you have wasted.

Edit: I was trying to set the environment variable based on your original post which includes a link to setting environment variables:

If you would like to test this behavior in your build environment ahead of June 15th, you can explicitly set the CI variable in your build or explicitly for an individual command like:

12

Hi there, as outlined above, the steps to remediate would either be to edit the netlify.toml file for the sites, or add the build command to the 12 sites in question as outlined above - let us know if you need more clarification on that, please!

I realize that making changes can disrupt workflows - totally get it, which is why we announced this change over a month ago, to give folks time to prepare. We do believe these changes are ultimately beneficial for the hundreds of thousands of customers on our system. Let us know what we can do to help!

1 Like
13

We have 230 projects. The ones you broke yesterday were a subset.

I have better things to do than peruse your forums.

You can help by unbreaking this.

I cannot overstate how furious I am.

1 Like
15

hi again - that’s a stack of sites! let’s get you back on the road - we sent you an email to the account you signed into the forums with! let us know if you don’t see it for some reason, please!

16

Hi @perry, I’m on the frontend team with @jacobs. Just a quick message to say that we’ve got the critical projects back online with the CI= change; we’ll work our way back through the older ones in the coming days. We’ll also be sure to keep a closer eye on the forum announcements to make sure we’re not caught out in the future.

In the past, emails have been sent out for breaking changes like these. Is that the best way to be sure we don’t get caught out again or is checking the forums regularly our best bet?

Thanks again for the solution!

2 Likes
17

hey rob, glad to hear you were able to make that change and get those projects unstuck - thats the most important thing here of course. We are still monitoring the situation on our end and if you identify more sites that need remediation (or would be time consuming for you to do) please just mention them in that helpdesk conversation so we can assist.

Everyone else - if you are dealing with indivdual sites - please comment here on this thread if the steps we described above don’t work for you or you need additional clarification!

18

I did misread part of the suggested fix thinking it required a commit (which is a problem when using preview builds, as we do extensively); that’s only the case for some of the options. For one though, the fix can be made via the deploy UI, which is much less hassle (as it applies to all within a site).

However, to have multiple multi-million dollar projects suddenly break for no reason is a big problem (on top of being massively stressful). In addition to the lost development time of multiple developers, I may now have bogus bugs to investigate and subsequently close and tickets erroneously rejected by QA. And I now have to explain this to clients, further wasting time.

The root of this problem though is you changing the established definition of “warning” to something that it isn’t. If we wanted this functionality, we could have easily done this ourselves in seconds.

1 Like
19

First, I’m not in any way trying to minimize your comments about the impact of this change to you and your clients. I’m not arguing that in any way.

For the purposes of transparency and an accurate record, there is one sentence that I would like to make some clarifications about. I’ve quoted that sentence below:

The root of this problem though is you changing the established definition of “warning” to something that it isn’t.

That isn’t what happened and that is one thing I want to clarify.

The only change is to now set CI=true as an environment variable by default. We did not change if our build systems is treating a warning as an error or not.

For some npm packages (and other software), the presence of this environment variable did cause warnings to be treated as errors. The environment variable does trigger different behavior in some software.

We introduced the environment variable only though. The warnings being treated as errors logic exists in the npm packages and not in our build system.

Why did we introduce this environment variable? Because it should have always been set. Our build system is part of a CI/CD process and it is an industry standard practice that these systems set CI=true in the environment where the builds occur.

For example, this often suppresses the printing of “spinners” and progress bars to logs when set. Adding this environment variable greatly improves the usability of build logs by preventing printing useless lines (which can be thousands or tens of thousands of lines for a single build in some cases).

To summarize, we added CI=true because it should have been set all along and adding it results in improved behavior in the vast majority of builds. This was not the case with your sites’ builds and there is no disputing that.

Again, I’m not disagreeing about the impact or about how we handled communications around this. I’m only clarifying this detail about what the actual change was (which is that we now add CI=true as a environment variable by default).

2 Likes
20

Have you all considered putting this article in the troubleshooting deployment section of your website or anything? I spent an hour trying to fix this this thinking it was my code changes and undoing commits before I found this discussion thread. Perhaps have it be a prompt that we can opt-in/out of instead?

1 Like
21

Hey,

Hindsight is definitely 20/20. We appreciate the feedback. At this stage, however, and in my opinion, changing the rollout again would be counterproductive.

1 Like