Distinguish CI command runs from the rest

[andremedeiros]

Right now, the commands are being reported and counted without differentiation as to their source.

@indirect suggests we should split them up by source when they run on CI systems.

A brief research wielded these environment variables we can use to pinpoint what CI system is running:

• Travis CI: TRAVIS (or, even better, HAS_JOSH_K_SEAL_OF_APPROVAL); /cc @joshk
• CircleCI: CIRCLECI (or any of the other env variables it sets when starting a container);
• Semaphore: SEMAPHORE;
• Jenkins: JENKINS_URL;
• Buildbox: BUILDBOX;
• Codeship: CI_NAME set to codeship;
• Go: GO_SERVER_URL;
• SnapCI: SNAP_CI;

Let me know if I've missed anything before I do the work for this.

[TimMoore]

I think a lot of different systems set CI=true, as a kind of de facto standard, so that's a good catch-all.

References:

• http://docs.travis-ci.com/user/ci-environment/#Environment-variables
• https://circleci.com/docs/environment-variables
• https://semaphoreapp.com/docs/available-environment-variables.html
• http://devcenter.wercker.com/articles/steps/variables.html
• https://buildbox.io/docs/guides/environment-variables
• https://codeship.io/documentation/continuous-integration/set-environment-variables/
• http://www.go.cd/documentation/user/current/faq/dev_use_current_revision_in_build.html
• http://docs.snap-ci.com/environment-variables/

[andremedeiros]

Thanks for the research, @TimMoore!

Wouldn't we want to distinguish which is which tho?

[TimMoore]

Maybe so... and those links show which variables each system uses... I was just thinking that CI could be used as a fallback.

There are a bunch of other CI/CD systems out there now that I've missed, too... seems to be a very active area.

[joshk]

Is something wrong with Travis support?

On Thu, Nov 6, 2014 at 12:11 AM, Tim Moore [email protected]
wrote:

Maybe so... and those links show which variables each system uses... I was just thinking that CI could be used as a fallback.

There are a bunch of other CI/CD systems out there now that I've missed, too... seems to be a very active area.

Reply to this email directly or view it on GitHub:
#3233 (comment)

[andremedeiros]

@joshk nothing at all, we're just planning on tagging command runs with specific CIs so that we can monitor those better.

[joshk]

@andremedeiros are you running the Bundler test suite on several CI systems?

[ixti]

@joshk that's for API usage monitoring :D

[joshk]

AAAHHHHHHHH

Well, we currently set a ruby agent for this. https://github.com/travis-ci/travis-cookbooks/blob/master/ci_environment/rvm/templates/default/bundler_config.yml.erb

But in any case, using TRAVIS or JOSH_K_SEAL_OF_APPROVAL is a good way to go.

[indirect]

Oh riiiiiight I completely forgot about that. I don't know if Bundler can even handle nested keys in its config, though. Checking the ENV is probably more reliable across services.

[joshk]

@indirect can you confirm/deny if our bundler config, which you advised us to add, is correct or not?

—
Sent from Mailbox

On Thu, Nov 6, 2014 at 4:56 PM, André Arko [email protected]
wrote:

Oh riiiiiight I completely forgot about that. I don't know if Bundler can even handle nested keys in its config, though. Checking the ENV is probably more reliable across services.

Reply to this email directly or view it on GitHub:
#3233 (comment)

[indirect]

@joshk to be honest, I can't even tell where that config ends up. Is it in ~/.bundle?

[joshk]

yes it is :)

[indirect]

@joshk change your file to look like this:

# ~/.bundle/config
BUNDLE_USER_AGENT: "travis-ci.<%= @suffix %>/1.0.0"

I added support for reading that in 8078db6.

[simi]

What about to distinguish command runs from non-interactive shells (CI, deploy, ...) also? But I'm not sure if that's easy to do universal check.

[fotanus]

If this turns out to be interesting, I can look for a way on how to do. Maybe open a new issue for that one?

[segiddins]

closed by #3646.