breakdown Build Definition / Process / Phases / Steps into objects

[KaiWalter]

PR Summary

With this PR Build Definition / Process / Phases / Steps are broken down into separate objects - see issue 64.

Now access to sub-objects is possible:

(Get-VSTeamBuildDefinition -ProjectName MyProject -Id 42).Process
(Get-VSTeamBuildDefinition -ProjectName MyProject -Id 42).Process.Phases
(Get-VSTeamBuildDefinition -ProjectName MyProject -Id 42).Process.Phases[0].Steps
(Get-VSTeamBuildDefinition -ProjectName MyProject -Id 42).Process.Phases[0].Steps[0]

PR Checklist

• Write Unit Test

[DarqueWarrior]

Just started testing and ran into an error.

m:\> cd .\PeopleTracker\
m:\PeopleTracker> dir

Mode   Name
----   ----
d----- Builds
d----- Build Definitions
d----- Releases
d----- Repositories
d----- Teams


m:\PeopleTracker> cd '.\Build Definitions\'
m:\PeopleTracker\Build Definitions> dir
dir : Item 'Build Definitions' may no longer exists. Details: Exception setting "CreatedOn": "Cannot convert null to type "System.DateTime".".
At line:1 char:1
+ dir
+ ~~~
    + CategoryInfo          : NotSpecified: (SHiPS:String) [Get-ChildItem], Exception
    + FullyQualifiedErrorId : ExceptionWhenSetting,Microsoft.PowerShell.Commands.GetChildItemCommand

m:\PeopleTracker\Build Definitions>

[KaiWalter]

Thanks. I'll look into it.

[DarqueWarrior]

I found it. I can correct it for you.

[KaiWalter]

Well thanks. Yes please correct it. I'm not yet familiar with that SHiPS Provider approach.

[DarqueWarrior]

yaml builds don't have phases which is causing some tricky behavior. You have done most of the heavy lifting I am just working to get it to support them both correctly.

[KaiWalter]

Should we add adding and getting a YAML build in the integration tests?

[DarqueWarrior]

Maybe. But I just ran into a much bigger problem. This is not a problem with what you submitted. The API version is not the same in the provider as it is in the rest of the module. For example when the module is loaded the versions default to 3.0 to support TFS2017. When you load a profile the module sets a version table to the new version. However, the classes never see that new version for some reason. They all the API calls are made using the 3.0 API which does not return the Process object of build definitions at all! So I have to work with the PowerShell team to figure out how to have my classes and module see the same values in $VSTeamVersionTable

[KaiWalter]

In your 2nd last comment (t-22h) : did you mean YAML or XAML builds which do not have phases?

[KaiWalter]

About the provider defaulting to API Version 3.0 instead of using 4.0 from the profile / modules: I'm also able to reproduce it.

For me it more looks like 2 different (process) contexts. API Version change with Add-VSTeamAccount only touches the version table visible for the modules. Provider keeps the initial setup from team.psm1.

[DarqueWarrior]

Correct. I just got an email back from the PowerShell team and think I have a workable solution. Will try to have it done today.

[DarqueWarrior]

I am reviewing the JSON returned from TFS 2017, 2018 and VSTS so see which properties are in each.

[DarqueWarrior]

Looks the build property from TFS was placed by the Process property in VSTS but the same "steps" are in all of them.

[DarqueWarrior]

Getting close. Huge refactor to get all this working. All the tests are passing again and works for TFS 2017/2018 and VSTS. I want to get some sleep and tests again in the morning before pushing changes.

[KaiWalter]

OK, looking forward to see what has changed. This is a great PowerShell learning experience for me.

[DarqueWarrior]

A lot has changed but none of it was your fault. Classes in PowerShell are challenging to say the least. They run in their own run space which causes issues that I had to work around. I really like being able to see the steps of a build def. So thanks for the PR. I also learned that the steps are in different places for TFS and VSTS.

[DarqueWarrior]

The version will be 4.0.0 because one of the changes is a breaking change. I will go ahead and push changes so you can review but I will not merge until after I test more tomorrow.

[KaiWalter]

Putting the changes in a new version 4.0.0 definitely makes sense. I wounder whether it makes sense to hold it back for some time - may be create a separate branch - until we transferred everything to classes. In Build Defs e.g. Queue, Repository should be also objects in order to allow a coherent experience for getting and setting later.

[DarqueWarrior]

I have it all working and we have already been move object by object to classes so I am ok with it being placed there now. So far things are looking ok.