[Bug Fix] - azuredevops_serviceendpoint_azurerm - Fix bug with serviceendpoint_azurerm when shared projectid gets mutil…

[leasley199]

bug with serviceendpoint_azurerm when shared projectID gets clobbered/mutilated.

All Submissions:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My code follows the code style of this project.
• I ran lint checks locally prior to submission.
• Have you checked to ensure there aren't other open PRs for the same update/change?

What about the current behavior has changed?

Currently there is a bug with the serviceendpoint_azurerm resource when the service connection gets shared to another project the projectid gets clobbered. this is because the value for the projectID is hardcoded to [0] and the object that this id is read from the order or IDs can change and thus break the resource.

[{"projectReference":{"id":"0000-id00001","name":"Project01"},"name":"AZDO-Project01","description":"Managed by Terraform"},{"projectReference":{"id":"0000-id00002","name":"Project02"},"name":"AZDO-Project02","description":"Managed by Terraform"}]

if the shared projectID is alphabetically/numerically greater than the initial projectID this will cause a mismatch and thus the resource is broken. The fix takes the field, matches the specified projected of the resource and continues if successful/else fail if not match (obviously ha ha).

This is probably an issue in all serviceendpoints that have the projectID hardcoded as [0] but in the effort of do no harm I am only targeting this resource.
The changes 'should' be able to lift and shift however if true.

Issue Number: NA

Does this introduce a change to go.mod, go.sum or vendor/?

• Yes
• No

Does this introduce a breaking change?

• Yes
• No

Any relevant logs, error output, etc?

current error tries to delete and recreate resource since projectID changes. This is undesired since it breaks the shared service connection resource and state becomes undesirable/falsified.

Test locally, but more eyes and insight never hurt many thanks :)

[xuzhang3]

@leasley199 Currently the project_id is being checked during the read(https://github.com/microsoft/terraform-provider-azuredevops/blob/main/azuredevops/internal/service/serviceendpoint/commons.go#L311). You should add this check to the read operation instead of the create operation. Also the validateServiceEndpoint should not removed, it is used to validate the service connection after setting the configuration and is the same as Verify and save.

[leasley199]

weird I can see the validateServiceEndpoint on my local branch untouched. noted on the read/create operation.

[xuzhang3]

weird I can see the validateServiceEndpoint on my local branch untouched. noted on the read/create operation.

Wrong PR? validateServiceEndpoint has been removed in this PR.

[leasley199]

alright new commit(s) should address the prior comment. I also added a parameter to the resource that cause the initial bug in the first place. When service connection is shared project Id was getting clobbered, now projectID will validate as well if the serv connection is shared with other projects this can be managed via tf now. If not included serv connection would remove shared projects from resource. staged in common.go so that it can be used by other service connection but not doing the leg work for that at the moment due to scope.

[xuzhang3]

@leasley199 Please help resolve the whitespace encoding issue. And can you help add the AccTest to cover the new changes(shared_project_ids) ?