[Feature] Detect Azure Pipelines

[vtbassmatt]

Add detection for Azure Pipelines.

Azure Pipelines is the new name for both TFS Build and VSTS Build. Detection is a little messy because we intentionally don't make it obvious whether you're running on-premises (Azure DevOps Server) or hosted (Azure DevOps Services). I left TF_BUILD as the indicator for TFS, and did URL path-math on our new domain name to check for Azure Pipelines.

[vtbassmatt]

Sorry for the confusion! The reason you don't see them on that page is they're spelled differently. We have non-environment-variable contexts where you say things like "System.TeamFoundationCollectionUri". That gets translated to "SYSTEM_TEAMFOUNDATIONCOLLECTIONURI" as an env var.

I will also follow your suggestion - didn't realize I was breaking stuff :)

[watson]

No worries.

Quick question: Do you think this PR will also fix issue #7? I've been trying to look into the differences between Team Foundation Server, Visual Studio Team Services and Azure Pipelines previously, but thought it was basically all just Team Foundation Server underneath - but maybe not?

[vtbassmatt]

Yeah, this should address #7 as well. Here's the story: TFS and VSTS are largely the same source code, but they're built and shipped completely differently. Most customer-observable behaviors, especially on CI agents, are identical. "Azure DevOps" is more than just a rebrand, but for purposes of this library, it's essentially a rebrand of VSTS. "Azure DevOps Server" is the new name for future versions of TFS.

[sibiraj-s]

Maybe after Sept-10-2018, https://azure.microsoft.com/en-us/blog/introducing-azure-devops/ ?

[watson]

@vtbassmatt Thanks for explaining.

Are there any ways to differentiate between TFS, VSTS and Azure DevOps Server by looking at environment variables (or other things) or do you recommend that this tool just classifies it all as the same?

If we should classify these as the same, I assume we should choose call it "Azure Pipelines" as you suggests with this PR?

[vtbassmatt]

I recommend they all get classified the same. In fact, I almost removed TFS with my PR, but I wasn't sure who it might break downstream.

Sorta by design, you can't easily detect which environment you're running against. You could do path-checking on a few of the variables, but that's fragile especially considering we just changed domains recently :)

[watson]

If a user is running their own TFS/VSTS environment I think they would be confused if we classified that as an Azure environment. Though the other way around might not be as confusing - so if you're running on Azure Pipelines, but gets told that it's actually TFS, then you might just accept that as an internal implementation detail. What do you think about that?

[vtbassmatt]

We're renaming TFS to Azure DevOps Server with the next version so there will likely be that confusion anyhow 😋. Let's go with Azure Pipelines.

[watson]

Could we call it "Azure DevOps Server" then, or is that confusing for people using "Azure Pipelines" you think? I guess it also depends on the percentages of people using this to detect CI. If 95% of people will be using Azure Pipelines you could argue that it makes sense to default to that 😅

[vtbassmatt]

That's kinda what I was thinking. My hunch is that the overlap of people using our on-premises offer, those detecting that they're running in CI using an npm module, and those who would be confused is... limited 😋

On Mon, Oct 1, 2018 at 12:20 PM Thomas Watson notifications@github.com wrote:

Could we call it "Azure DevOps Server" then, or is that confusing for people using "Azure Pipelines" you think? I guess it also depends on the percentages of people using this to detect CI. If 95% of people will be using Azure Pipelines you could argue that it makes sense to default to that 😅

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/watson/ci-info/pull/23#issuecomment-425969861, or mute the thread https://github.com/notifications/unsubscribe-auth/AArmK56Ydpfc7w8YyqD0-NRq-D3_wSEqks5ugkDegaJpZM4W5tFH .

[watson]

Ok, let's go with this then and see if people complain. Thanks for being patient with all my questions 😄

Will the TF_BUILD environment variable also be available in Azure Pipeline?

If so, the logic for detecting the right CI system might be confused and choose TFS instead of Azure Pipelines based on how the detection algorithm currently works. In that case it's probably best to make this a breaking change.

[vtbassmatt]

Yes, TF_BUILD exists on both. I'm all for making this a breaking change.

[DSchau]

Any chance someone could give this another set of 👀? We could really use this in gatsbyjs/gatsby#10140

Thank you!

[watson]

Sorry, dropped the ball on this one 😅

[DSchau]

@watson it happens! Thanks so much for merging.

Can you let us know when it's published?

[watson]

Will do

[watson]

Support for Azure Pipelines has just been released in v2.0.0