Support for seeing provider version history of each resource type

[phatcher]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

I'm maintaining a module framework (~70 resource types) for building Azure PaaS applications and so I have to align it's capabilities against the versions of each resource within the AzureRm provider.

For safety/consistency, each module is locked to the specific provider version and to see if I have any work to do, I have to examine each release to see if it covers a type that has been implemented and it it has an impact on the module framework,

What would be nice is a per-resource type version history so I can quickly scan the interesting resource types. I understand it might be of limited use to most people but would also help when migrating scripts rather than updating to the latest and fixing any issues.

I'm hoping this is fairly easily implemented by processing the version log/commit history, if not please ignore

New or Affected Resource(s)/Data Source(s)

azurerm_XXXX

Potential Terraform Configuration

No response

References

No response

[aristosvo]

I really like this idea! Would be great to have an overview of changes of only the used resources before a module gets upgraded!

It should not be to hard to script something specific for azurerm, but this might in the end be something that could end up in core I'd say.

[lonegunmanb]

Maybe we can provide a tool that scan CHANGELOG file for such line:

• New Resource: azurerm_sentinel_metadata [New Resource: azurerm_sentinel_metadata #20801]

Then we could get a resource/data - version map.

[phatcher]

That get's you the version a resource is created in, but not when a change is introduced or a bug fixed

You do have enhancement and bug fix lines that might help e.g.

azurerm_app_service_connection - support for the secret_store block (#20613)

azurerm_cdn_frontdoor_origin - origin_host_header can now be cleared once it has been set (#20679)

Funnily enough - just encounter the FD origin host header bug last week ;-)

And the bug report/enhancement might also allow tracking to a resource type. This would get 90% of them, some are a bit more problematic in that the naming doesn't help associate to a resource type

signalr: refactoring to use hashicorp/go-azure-sdk as a base layer rather than Azure/go-autorest (#20688)

But I'm not sure those are directly relevant.

So you have three phases I think

1. Scan each changelog emitting the version, resource, change type, details
2. Merge all outputs into a central resource/version map e.g. azure_cdn_frontdoor_origin introduced 3.7.0, last updated 3.46.0
3. Merge all outputs per resource type providing the version history for that resource

[tombuildsstuff]

hey @phatcher

Thanks for opening this issue.

Taking a look through here unfortunately this probably isn't something we're able to provide since the information within the changelog is intended for human consumption rather than intended to be processed in an automated fashion.

Whilst we endeavour for this to contain information about every resource affected by a given change, since this is computed by hand it's possible for these items to be phrased slightly differently - and so there isn't a reliable means of doing this unfortunately. One such example would be updating the Base Layer used in hashicorp/go-azure-sdk - doing so will affect all resources, but the change isn't user-facing - and so isn't something which would directly enter the CHANGELOG (updating the SDK would, the specific change within the base layer likely wouldn't) - as such unfortunately the CHANGELOG file doesn't contain enough contextual information to be able to surface this information in an automated manner.

Whilst you'd be welcome to build your own tooling around this (and given the folder structure of the provider, I'd probably look to use the specific file paths to determine which resources are likely affected) - unfortunately this isn't something we plan to provide at this time and as such I'm going to close this issue for the moment. That said, I do think there's an interesting point here around making upgrades easier/more obvious, and as such I'd encourage you to open an issue on the hashicorp/terraform repository where someone from the Terraform Core team should be able to take a look.

Thanks!

[magodo]

@phatcher I have a tool that can generate a change report between two provider versions, in terms of schema changes, if you are interested in: https://github.com/magodo/tfpluginbcd

[phatcher]

@tombuildsstuff Thanks for the update, I realized it was a stretch

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.