Export not working for on-premises versions of Azure DevOps

[hideintheclouds]

@tsteenbakkers The current configuration does not support Azure DevOps on premises, due to the hardcoding of the host in Get-AzdoAPIURL.ps1 ( $sb.Append('dev.azure.com') | Out-Null)
I was able to make minimal changes to have this working with On-premises AzDO, by adding the following changes:

• Get-AzdoAPIURL.ps1 (starting with line 16):

  `$profile = Get-AzdoAPIToolsProfile -profilename $profilename
   $subdomain = $profile.Organization
   $baseUrl = If ([string]::IsNullOrWhiteSpace($profile.collectionUrl)) {'dev.azure.com'} Else {$profile.collectionurl}
   
   $sb = New-Object System.Text.StringBuilder
  
   $sb.Append('https://') | Out-Null
   if($area -eq 'Release'){
      $sb.Append('vsrm.') | Out-Null
   }
   $sb.Append($baseUrl) | Out-Null`
  

• Get-AzdoAPIURL.ps1 (adding a new variable for the collectionUrl):
  $collectionUrl = Read-Host -prompt "Optional: Please provide the collection url if the instance of Azure DevOps is on premisses(tfs.yourlocalserver/tfs). The protocol is not needed"

[tsteenbakkers]

Hey Adrian, Thanks for your e-mail. The published version does indeed only work with the SAAS version of Azure DevOps. I'm not if i stated that clearly in the documentation. I haven't been able to test the on premise version of the tool yet, because I don't have one. I was afraid that the API endpoints (not just the baseurl) were different for on premise. Azure DevOps is a weird MS product and it would surely not have surprised me if they would. So thank you a lot for testing this and pointing this out to me. Does the rest of the tool work properly while using azure devops server (on premise)? if so would you be so kind to create a pull request of the mentioned changes so I can incorporate them into the tool and give you credit for it? Regards, Tobi

…

On Wed, Jun 30, 2021 at 6:39 PM Adrian Marian ***@***.***> wrote: @tsteenbakkers <https://github.com/tsteenbakkers> The current configuration does not support Azure DevOps on premises, due to the hardcoding of the host in Get-AzdoAPIURL.ps1 ( $sb.Append('dev.azure.com') | Out-Null) I was able to make minimal changes to have this working with On-premises AzDO, by adding the following changes: - Get-AzdoAPIURL.ps1 (starting with line 16): `$profile = Get-AzdoAPIToolsProfile -profilename $profilename $subdomain = $profile.Organization $baseUrl = If ([string]::IsNullOrWhiteSpace($profile.collectionUrl)) {'dev.azure.com'} Else {$profile.collectionurl} $sb = New-Object System.Text.StringBuilder $sb.Append('https://') | Out-Null if($area -eq 'Release'){ $sb.Append('vsrm.') | Out-Null } $sb.Append($baseUrl) | Out-Null` - Get-AzdoAPIURL.ps1 (adding a new variable for the collectionUrl): $collectionUrl = Read-Host -prompt "Optional: Please provide the collection url if the instance of Azure DevOps is on premisses(tfs.yourlocalserver/tfs). The protocol is not needed" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDI5FT2W6H4ORDEE4OOIATTVNCEVANCNFSM47SWR7GQ> .

-- Met vriendelijke groeten, Tobi Steenbakkers about.me/tsteenbakkers [image: Tobi Steenbakkers on about.me] <http://about.me/tsteenbakkers>

[hideintheclouds]

Hey Tobi,

According to the Azure DevOps REST api documentation (https://docs.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-6.1):

A REST API request/response pair can be separated into five components:

The request URI, in the following form: VERB https://{instance}[/{team-project}]/_apis[/{area}]/{resource}?api-version={version}

instance: The Azure DevOps Services organization or TFS server you're sending the request to. They are structured as follows:
Azure DevOps Services: dev.azure.com/{organization}
TFS: {server:port}/tfs/{collection} (the default port is 8080, and the value for collection should be DefaultCollection but can be any collection)

I think the rest of the calls should be the same, just have to set the instance to {server:port}/tfs/. In my example, I am using the organization in the config for the {collection} above.

I have tested this partially with an on-premises instance of Azure DevOps (without internet connection) and it seems to work nicely for extracting and saving the TaskGroups and BuildDefinitions.
I have not tested the other methods (i.e. variables, triggers, etc).

I am not sure I have rights to commit/create pull requests, so I have forked the repo and commited the change here:

hideintheclouds@ca11f9c

Please let me know if there is anything I could do for the PR.

Thanks,
Adrian

[tsteenbakkers]

Hey Adrian, Thanks for the additional information. Reading it I think the on premise Azure DevOps Server product will have roughly the same API availability as Azure DevOps as a Service. maybe it will depend on how well you do with installing updates as that will be a manual service to maintain on premise. I think for TFS we have a different issue since TFS is officially not supporting YAML pipelines and Microsoft has stopped developping the REST API on TFS past version 5.0-preview iirc from my past experience as an engineer at previous customers. I will have a look if I can find a customer / client of mine which still has a TFS instance running to see if all the endpoints I use in the tool are working on a TFS machine. One of the future features i had planned was importing the created YAML constructs as a YAML pipeline into Azure DevOps but that will be functionality then not working on TFS ofcourse. Thanks for the fork and branch. I'll have a look if i can create a PR from the fork to the origin (my repo) to have the change incorporated. If not I will simply copy over the newly added code since it not that much. I will let you know if I need something from you to incorporate the change. Last question: are you ok if i mention your GitHub profile in the release notes / documentation for contributing to the tool? Regards, Tobi

…

On Thu, Jul 1, 2021 at 5:57 PM Adrian M ***@***.***> wrote: Hey Tobi, According to the Azure DevOps REST api documentation ( https://docs.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-6.1 ): _A REST API request/response pair can be separated into five components: The request URI, in the following form: VERB https:// {instance}[/{team-project}]/_apis[/{area}]/{resource}?api-version={version} *instance: The Azure DevOps Services organization or TFS server you're sending the request to. They are structured as follows: Azure DevOps Services: dev.azure.com/{organization} <http://dev.azure.com/%7Borganization%7D> TFS: {server:port}/tfs/{collection} (the default port is 8080, and the value for collection should be DefaultCollection but can be any collection)*_ I think the rest of the calls should be the same, just have to set the instance to {server:port}/tfs/. In my example, I am using the organization in the config for the {collection} above. I have tested this partially with an on-premises instance of Azure DevOps (without internet connection) and it seems to work nicely for extracting and saving the TaskGroups and BuildDefinitions. I have not tested the other methods (i.e. variables, triggers, etc). I am not sure I have rights to commit/create pull requests, so I have forked the repo and commited the change here: ***@***.*** <hideintheclouds@ca11f9c> Please let me know if there is anything I could do for the PR. Thanks, Adrian — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDI5FT6JHVUE6MYRIIEHT3TVSF6XANCNFSM47SWR7GQ> .

-- Met vriendelijke groeten, Tobi Steenbakkers about.me/tsteenbakkers [image: Tobi Steenbakkers on about.me] <http://about.me/tsteenbakkers>

[hideintheclouds]

Hi Tobi,

Regarding the Azure Devops Server and the updating process, I think you are spot on, and that each client will apply their updates manually.

I am not sure how many companies are still using TFS, probably some of them have already migrated to Azure Devops Server.
Note: I have tested the previous change with Azure DevOps Server 2020, unfortunately I cannot use an older version, like TFS to confirm that it above work as expected.

In regards to the Github profile mentioning, that's not a problem at all.

Kind regards,
Adrian