feat: add dependency check step to build pipeline

[tadelesh]

• The purpose of this PR is explained in this or a referenced issue.
• The PR does not update generated files.
  • These files are managed by the codegen framework at Azure/autorest.go.
• Tests are included and/or updated for code changes.
• Updates to CHANGELOG.md are included.
• MIT license headers are included in each file.

[tadelesh]

Incompatible dependency with different packages will cause mod auto-resolving failure when customer import multiple v2 packages including data plane and mgmt. plane SDK. This script added to build process will import all the v2 modules and try to resolve dependency as well as build and vet to ensure any update not breaking the package compatible. But it still exists a chicken and egg situation. This step will fail if any breaking change in common package like azcore has not applied to all packages. I have no perfect solution. So I just ignore the check for the first layer dependent common packages.

[jhendrixMSFT]

This shouldn't be a problem post-GA. Seems expensive to build the world for each PR.

[tadelesh]

This shouldn't be a problem post-GA. Seems expensive to build the world for each PR.

According to ci log, it will take about 3.5mins in average. It seems expensive indeed, but I think maybe it is valuable before GA as we may have multiple breaking changes. I don't know whether there is a more economic way to do such check, maybe we could just use it temporary and keep it as a tool after GA. @lirenhe @ArcturusZhang what do you think?

[seankane-msft]

/azp run go - azkeys

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[seankane-msft]

/azp run go - azkeys

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[seankane-msft]

@tadelesh in the tests run against azkeys, the go build command fails with exit code 1 but without any details on what the error is. Does this work locally for you?

[tadelesh]

/azp run go - azkeys

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tadelesh]

@tadelesh in the tests run against azkeys, the go build command fails with exit code 1 but without any details on what the error is. Does this work locally for you?

I've removed all the -x flag in go build cmd to give a more readable log. @seankane-msft You can get the error for azkeys for now.

[seankane-msft]

I've removed all the -x flag in go build cmd to give a more readable log. @seankane-msft You can get the error for azkeys for now.

Thanks for removing that flag, the output is much clearer now. I have a fix for that once I can release changes to internal. For now that should not be blocking on this PR.

[tadelesh]

I've removed all the -x flag in go build cmd to give a more readable log. @seankane-msft You can get the error for azkeys for now.

Thanks for removing that flag, the output is much clearer now. I have a fix for that once I can release changes to internal. For now that should not be blocking on this PR.

@seankane-msft If this PR merge first, will it be conflict with the 'nightly build' change you are doing?

@benbp @weshaggard Could you help to have a review?

[seankane-msft]

I've removed all the -x flag in go build cmd to give a more readable log. @seankane-msft You can get the error for azkeys for now.

Thanks for removing that flag, the output is much clearer now. I have a fix for that once I can release changes to internal. For now that should not be blocking on this PR.

@seankane-msft If this PR merge first, will it be conflict with the 'nightly build' change you are doing?

I don't believe so.

[seankane-msft]

LGTM

[tadelesh]

/azp run go - azkeys

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tadelesh]

/azp run go - azkeys

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[weshaggard]

A couple comments but looks good.

[tadelesh]

/check-enforcer override

[jhendrixMSFT]

I'm unclear why this was merged, especially when we a) have breaking changes that haven't been released yet and b) have a few more on the way (you can see that CI failed in this PR even). I thought this was going to be enabled post-GA?

[benbp]

The check enforcer should not have been overridden here (at the very least without a comment on justification) when the pipeline failure was a direct result of the change.

[tadelesh]

The check enforcer should not have been overridden here (at the very least without a comment on justification) when the pipeline failure was a direct result of the change.

Got it. This check is a chicken-and-egg conundrum. So I just bypassed it if any breaking change is intentional. It's good to be set as an optional before GA.