[JENKINS-36707] Set environment variable CI=true on all builds

[jenkins-infra-bot]

Very simple: set & expose environment variable `CI=true` on all builds as TravisCI or Drone or CircleCI or other CI tools do.

---

Originally reported by danielbeck2, imported from: Set environment variable CI=true on all builds

• assignee: manus
• status: Closed
• priority: Minor
• component(s): core, plugin-proposals
• label(s): environment-variables
• resolution: Fixed
• resolved: 2021-03-30T16:44:50+00:00
• votes: 3
• watchers: 4
• imported: 2025-11-24

Raw content of original issue

Very simple: set & expose environment variable `CI=true` on all builds as TravisCI or Drone or CircleCI or other CI tools do.

• environment: ANY, e.g. jenkins:2.13

[jenkins-infra-bot]

• Remote link associated with this issue:

  • GitHub: Add CI environment variable (jenkinsci/jenkins#​5370)

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  So the dozen or so other environment variables defined by Jenkins don't work for you?
  
  This needs a real rationale.
  

So the dozen or so other environment variables defined by Jenkins don't work for you?

This needs a real rationale.

[jenkins-infra-bot]

elgalu:

• Original comment link
• Raw content of original comment:

  This makes it easier to migrate from TravisCI or CircleCI to Jenkins for example.
  Some things are cross browser compatible, others are cross operating system, this would be cross CI.
  

This makes it easier to migrate from TravisCI or CircleCI to Jenkins for example.
Some things are cross browser compatible, others are cross operating system, this would be cross CI.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Best done as a separate plugin I think. Should be trivial enough, sample-code sized.
  

Best done as a separate plugin I think. Should be trivial enough, sample-code sized.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  FWIW unless you have a giant (but manually managed) set of build agents, it's trivial enough to define one env var on master and each of the agents. This will be inherited by all the builds (possibly only after a restart, but shouldn't matter here).
  

FWIW unless you have a giant (but manually managed) set of build agents, it's trivial enough to define one env var on master and each of the agents. This will be inherited by all the builds (possibly only after a restart, but shouldn't matter here).

[jenkins-infra-bot]

elgalu:

• Original comment link
• Raw content of original comment:

  I can think tons of workarounds but the idea was more like knowing this is the default on every Jenkins instance. Doing it via a plugin won't help, nobody will trust the plugin is installed and will simply check for well known Jenkins environment variables instead.
  
  IMHO this should be the default at jenkins-core or we simply stay as we are now.
  

I can think tons of workarounds but the idea was more like knowing this is the default on every Jenkins instance. Doing it via a plugin won't help, nobody will trust the plugin is installed and will simply check for well known Jenkins environment variables instead.

IMHO this should be the default at jenkins-core or we simply stay as we are now.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  I understood this as a compatibility feature for someone who switches from one of the other tools to Jenkins. That kind of feature should not be out of the box, especially given what else we're splitting off into plugins: https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%20split-plugins-from-core
  
  But apparently I'm still wrong? Who are you targeting with this? What's the use case? And how is that not covered by any of the following?
  
  
  	
  Indicate it's a CI system via env vars – we have e.g. JENKINS_COOKIE for this.
  	
  Allow easy migration of scripts – set the CI env var on nodes
  	
  "plug and play" of repositories, like travis.yml – Pipeline (Jenkinsfile) which is part of default 2.x installs of Jenkins
  
  
  
  Can't help the impression that there are substantial unvoiced assumptions/circumstances in this request.
  

I understood this as a compatibility feature for someone who switches from one of the other tools to Jenkins. That kind of feature should not be out of the box, especially given what else we're splitting off into plugins: https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%20split-plugins-from-core

But apparently I'm still wrong? Who are you targeting with this? What's the use case? And how is that not covered by any of the following?

• Indicate it's a CI system via env vars – we have e.g. JENKINS_COOKIE for this.
• Allow easy migration of scripts – set the CI env var on nodes
• "plug and play" of repositories, like travis.yml – Pipeline (Jenkinsfile) which is part of default 2.x installs of Jenkins

Can't help the impression that there are substantial unvoiced assumptions/circumstances in this request.

[jenkins-infra-bot]

elgalu:

• Original comment link
• Raw content of original comment:

  I'm pretty sure I'll see this in Jenkins eventually, is not the first time someone resists certain ideas/features, it already happened to me with docker HEALTHCHECK with endless discussions of why and is already in place in docker beta 1.12 
  
  Shouldn't be that difficult, `export CI=true` and what is there to lose.
  
  But honestly, if has already been decided not to do it I prefer you close this request, just trying to avoid another endless discussion that's all.
  

I'm pretty sure I'll see this in Jenkins eventually, is not the first time someone resists certain ideas/features, it already happened to me with docker HEALTHCHECK with endless discussions of why and is already in place in docker beta 1.12

Shouldn't be that difficult, `export CI=true` and what is there to lose.

But honestly, if has already been decided not to do it I prefer you close this request, just trying to avoid another endless discussion that's all.

[jenkins-infra-bot]

grv87:

• Original comment link
• Raw content of original comment:

  Use case: generic plugin for build system (e.g. Gradle) needs to detect whether it is run under CI or not.
  Not tying to specific project, instance, job configuration and so on.
  
  Jenkins is special and requires separate code branch.
  
  But, since there are dozens of old versions that don't expose CI=true - that separate code branch should exists for a long time anyway.
  

Use case: generic plugin for build system (e.g. Gradle) needs to detect whether it is run under CI or not.
Not tying to specific project, instance, job configuration and so on.

Jenkins is special and requires separate code branch.

But, since there are dozens of old versions that don't expose CI=true - that separate code branch should exists for a long time anyway.

[jenkins-infra-bot]

dragon788:

• Original comment link
• Raw content of original comment:

  Npm currently looks for `CI` being set to limit the verbosity of `npm install` and to disable showing progress which usually just bloats CI system logs (including on Jenkins). Not exporting `CI=true` means that Jenkins has to deal with larger logs and the performance tends to suffer pretty quickly when they rocket past 5MB due to complex Javascript projects pulling in hundreds (or thousands) of dependent packages.
  

Npm currently looks for `CI` being set to limit the verbosity of `npm install` and to disable showing progress which usually just bloats CI system logs (including on Jenkins). Not exporting `CI=true` means that Jenkins has to deal with larger logs and the performance tends to suffer pretty quickly when they rocket past 5MB due to complex Javascript projects pulling in hundreds (or thousands) of dependent packages.

[jenkins-infra-bot]

joerg_baeuerle:

• Original comment link
• Raw content of original comment:

  Create-React-App also checks for the `CI` environment variable. The official documentation mentions 
  By default npm test runs the watcher with interactive CLI. However, you can force it to run tests once and finish the process by setting an environment variable called CI. [...] Popular CI servers already set the environment variable CI by default.
  see https://create-react-app.dev/docs/running-tests#continuous-integration.
  
  I would consider Jenkins being a "popular CI server" and create-react-app an extremely popular tool in web fronted development. So maybe this should be a default in Jenkins?!
  

Create-React-App also checks for the `CI` environment variable. The official documentation mentions 

By default npm test runs the watcher with interactive CLI. However, you can force it to run tests once and finish the process by setting an environment variable called CI. [...] Popular CI servers already set the environment variable CI by default.

see https://create-react-app.dev/docs/running-tests#continuous-integration.

I would consider Jenkins being a "popular CI server" and create-react-app an extremely popular tool in web fronted development. So maybe this should be a default in Jenkins?!

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Maybe.
  
  Does the same apply to CONTINUOUS_INTEGRATION, why or why not?
  
  FWIW https://github.com/watson/ci-info/blob/f43f6a1cefff47fb361c88cf4b943fdbcaafe540/index.js#L53-L56 looks like a reasonable reference on which tools define which env vars.
  

Maybe.

Does the same apply to CONTINUOUS_INTEGRATION, why or why not?

FWIW https://github.com/watson/ci-info/blob/f43f6a1cefff47fb361c88cf4b943fdbcaafe540/index.js#L53-L56 looks like a reasonable reference on which tools define which env vars.

[jenkins-infra-bot]

joerg_baeuerle:

• Original comment link
• Raw content of original comment:

  Does the same apply to CONTINUOUS_INTEGRATION, why or why not?
  
  What exactly do you mean? Does what apply to CONTINUOUS_INTEGRATION?
  

Does the same apply to CONTINUOUS_INTEGRATION, why or why not?

What exactly do you mean? Does what apply to CONTINUOUS_INTEGRATION?

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

  Whether it should be added. This issue is only asking for CI to be added. The library I found supports CONTINUOUS_INTEGRATION to determine whether it runs in CI as well, which is apparently set by some tools.
  

Whether it should be added. This issue is only asking for CI to be added. The library I found supports CONTINUOUS_INTEGRATION to determine whether it runs in CI as well, which is apparently set by some tools.

[jenkins-infra-bot]

joerg_baeuerle:

• Original comment link
• Raw content of original comment:

  Ah, I see. However, it looks like those servers (Travis, Cirrus) who set CONTINUOUS_INTEGRATION do also set CI. So mabye CI would be sufficient.
  

Ah, I see. However, it looks like those servers (Travis, Cirrus) who set CONTINUOUS_INTEGRATION do also set CI. So mabye CI would be sufficient.