Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-36707

Set environment variable CI=true on all builds

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

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

          Daniel Beck added a comment -

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

          This needs a real rationale.

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

          Leo Gallucci added a 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.

          Leo Gallucci added a 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.

          Daniel Beck added a comment -

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

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

          Daniel Beck added a 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).

          Daniel Beck added a 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).

          Leo Gallucci added a 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.

          Leo Gallucci added a 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.

          Daniel Beck added a 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.

          Daniel Beck added a 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.

          Leo Gallucci added a 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.

          Leo Gallucci added a 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.

          Basil Peace added a 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.

          Basil Peace added a 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.

          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.

          Ethan Spoelstra added a 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.

          Joerg Baeuerle added a comment - - edited

          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?!

          Joerg Baeuerle added a comment - - edited 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?!

          Daniel Beck added a comment - - edited

          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.

          Daniel Beck added a comment - - edited 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.

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

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

          Joerg Baeuerle added a comment - Does the same apply to CONTINUOUS_INTEGRATION , why or why not? What exactly do you mean? Does what apply to CONTINUOUS_INTEGRATION ?

          Daniel Beck added a 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.

          Daniel Beck added a 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.

          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.

          Joerg Baeuerle added a 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.

          Leo Gallucci added a comment -

          I opened this issue 4 years ago, so much discussion for such a tiny change.

          Closing it now as I don't use Jenkins anymore.

          Leo Gallucci added a comment - I opened this issue 4 years ago, so much discussion for such a tiny change. Closing it now as I don't use Jenkins anymore.

          Daniel Beck added a comment -

          No need to close a reasonable request just because you don't need it anymore, votes and watchers indicate others are interested.

          Daniel Beck added a comment - No need to close a reasonable request just because you don't need it anymore, votes and watchers indicate others are interested.

          Leo Gallucci added a comment -

          can you remove me? I keep getting notifications even though I'm not a watcher

          Leo Gallucci added a comment - can you remove me? I keep getting notifications even though I'm not a watcher

          elgalu thanks for the community effort!

          danielbeck thanks for reopening.

          Joerg Baeuerle added a comment - elgalu thanks for the community effort! danielbeck thanks for reopening.

          manus added a comment -

          manus added a comment - Done in https://github.com/jenkinsci/jenkins/pull/5370 .

            manus manus
            danielbeck2 Not Daniel Not Beck
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: