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

          Leo Gallucci created issue -

          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 made changes -
          Component/s New: plugin-proposals [ 15491 ]
          Component/s Original: core [ 15593 ]

          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.
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 173436 ] New: JNJira + In-Review [ 185126 ]

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

              Created:
              Updated:
              Resolved: