Change project structure

[fatal10110]

I suggest to change the project structure, I guess it should be something like in python client
https://github.com/Microsoft/azure-devops-python-api/tree/dev/vsts/vsts

package for each type of azure devops object, with its own models

WDYT?

[benmatselby]

Hi there @fatal10110

What value does that add, over what is currently there? I structured this based on https://github.com/google/go-github, which seems very much like a go way of doing it. I'm not sure what value is added to restructure this?

[fatal10110]

Hi @benmatselby

1. I don't see support for different versions there, it may be difficult to maintain it as big flat project/one file per entity

2. Namespacing - Currently there is only one package/namespace, but azure devops can return the same entity with different fields/structure on different apis, for example in BuildsList it returns different Repository fields than Repository in BuildDefinition

[benmatselby]

@fatal10110 I hadn't thought of this (Due to my lack of knowledge around the DevOps API - I've only really just started using it)

What would the import path be for consumers of the API?

"github.com/benmatselby/go-azuredevops/azuredevops/v4.1"
"github.com/benmatselby/go-azuredevops/azuredevops/vx.y"

etc?

[mcdafydd]

One thing that I think should be considered is the level of effort required to maintain the code over time. The azure-devops-python-api and azure-devops-node-api repos are both primarily generated code from, if I understand correctly, Microsoft's internal, non-public, API definition files. The hand-written code is a small portion of the libraries. As the Azure Devops API develops, there is minimal maintenance, since the parts that changed are just re-generated.

I just came across a related issue working with webhook support in my fork. Some of the Azure Devops webhooks support several different resource versions. For Github, the webhooks have a clearly documented page at https://developer.github.com/webhooks/. I can't find something as clear for Azure Devops on the Microsoft Service Hooks documentation pages. But as a user who just wants the library to work, I think there would be value in defining all the webhook payload versions we know of and parsing the "resourceVersion" field. Example:

...
"resourceVersion": "1.0",
  "resourceContainers": {
    "collection": {
      "id": "76479225-aa3-4965-be93-1bce3d11aa34",
      "baseUrl": "https://example.visualstudio.com/"
    }
  },
  "createdDate": "2019-06-30T05:29:03.5448913Z"

[mcdafydd]

There is a repository with swagger files for the API, but they are used to generate the documentation and don't work with things like go-autorest out of the box (I tried):

MicrosoftDocs/vsts-rest-api-specs#161 (comment)

[benmatselby]

Hey @mcdafydd

To be honest, this started out as a way for me to learn Go, and started in my donny repo. I would have preferred to have used a VSTS (as it was called) library, but one didn't exist. My knowledge of Go was low, and also very low for VSTS. We had just started using it at work.

I am now no longer using VSTS (Azure DevOps now) in any capacity. I don't even have an account anymore to test changes to #31 or any changes to my donny repo (not that I would work on that since I don't use it anymore)

So, reality hits home, that I cannot really maintain this repo. So I'm happy for folks to fork this and publish their versions instead. Apologies to the folks using this.

[mcdafydd]

No worries, @benmatselby . Your efforts gave me a huge jump-start for an ongoing project, so thanks again. I'll keep developing in my fork. Best regards