hashicorp/go-azure-sdk - grouped submodules

[tombuildsstuff]

We’re looking to generate the SDKs for both microsoft-graph and resource-manager into hashicorp/go-azure-sdk.

However considering the size of each SDK (particularly microsoft-graph) in order to achieve this we’re going to need to split the hashicorp/go-azure-sdk repository up into 3 nested Go modules, namely:

1. github.com/hashicorp/go-azure-sdk/sdk
2. github.com/hashicorp/go-azure-sdk/microsoft-graph
3. github.com/hashicorp/go-azure-sdk/resource-manager

Whilst we could seek to version these separately (for example tagging the sdk directory by hand, and then updating the resource-manager and microsoft-graph directories automatically) - in practice we might as well release all 3 modules at the same time, meaning that we have one semantic version number for the entire SDK.

This means that we’ll end up with more Git Tags over time (since each release will become 3 separate Git Tags - one per submodule) - but means that we don’t need to be concerned with the modules falling out of sync.

As an example, running the release script today releases a version in the format v0.20240110.1174848, however with these changes the following Git Tags would be published:

1. sdk/v0.20240110.1174848
2. microsoft-graph/v0.20240110.1174848
3. resource-manager/v0.20240110.1174848

---

I’ve done some investigation of this, and it appears that this would entail:

1. Adding a go.mod and go.sum (and README.md, for convenience) to the microsoft-graph, resource-manager and sdk directories.
2. Updating the release script to first tag the sdk Go module, then (for both microsoft-graph and resource-manager) update the reference to the sdk module and release it.
3. A one-time release (and push) of the sdk module to ensure it exists - followed by a one-time manual update of both the microsoft-graph and resource-manager Go modules to reference the new sdk version.

At which point the regular release script should be able to handle releasing the SDK.

The branch containing the investigation can be found here: hashicorp/go-azure-sdk@main...tombuildsstuff:go-azure-sdk:f/submodules-per-type (intentionally done in a complete fork of the repository).

A branch containing one commit updating the user (so as to not pollute the hashicorp repository with tags during development) - which allows running ./scripts/determine-and-publish-git-tag.sh to trigger a release can be found in: https://github.com/tombuildsstuff/go-azure-sdk/tree/f/tombuildsstuff-module-tagging

---

Once that’s done, we’d then need to:

1. ✅ manicminer/hamilton: update to use the new Go Submodule.
2. ✅ hashicorp/terraform-provider-azurerm: update to account for the updated Go submodule structure.
3. ✅ hashicorp/terraform-provider-azurerm: update the tools/update-go-azure-sdk tool to account for multiple submodules existing/needing to be updated. tools/update-go-azure-sdk: updating both the Base Layer and Resource Manager submodules terraform-provider-azurerm#24602
4. ✅ hashicorp/go-azure-sdk - the release script will need updating to account for there being multiple Git Tags available.
5. ✅ hashicorp/terraform-provider-azuread: update to account for the updated Go submodule structure.
6. ✅ tombuildsstuff/azurerm-dalek: update to use the new Go Submodule.
7. ✅ tombuildsstuff/giovanni: update to use the new Go Submodule.

---

Whilst we also need to update ./tools/generator-go-sdk (to generate the Graph SDK) and tools/importer-msgraph-metadata (to write the API Definitions for Graph) in this repository to account for that - however this task is really a prerequisite for that (and requires coordination across the downstream tooling, so needs to be done sooner rather than later.

[tombuildsstuff]

This has now been rolled out:

• https://pkg.go.dev/github.com/hashicorp/go-azure-sdk/microsoft-graph
• https://pkg.go.dev/github.com/hashicorp/go-azure-sdk/resource-manager
• https://pkg.go.dev/github.com/hashicorp/go-azure-sdk/sdk

And vendored into each of the projects listed above.