terraform-provider-azuredevops: Error while installing microsoft/azuredevops v0.9.0: checksum list has │ unexpected SHA-256 hash

Thanks to @jaredfholgate for the workaround.

Sorry to bring this error to the provider. An attempt was made to update the document, but unexpectedly the provider was also updated, which also updated the SHA hash.

v0.9.0 will not be restored. Users have just upgraded their ADO provider to v0.9.0 will have the same issue if restored

A new version v0.9.1 has been released. Please update the provide with terraform init -upgrade

This issue is blocking us as well since today. Can this be given high prio? Thank you

How is it blocking as you can simply use 0.8.0?

@xuzhang3 man look how many people are leveraging this provider every day! maybe MS can see this and get more devs on the project.

For anyone following this, I did message Xu when I spotted this issue earlier today, but he was offline. He is in China time zone and I am sure will resolve first thing in his time zone (approx 1am GMT).

In the meantime, if you can downgrade to 0.8.0 for anything urgent. If you are reliant on 0.9.0 functionality I’m afraid there is not a simple workaround right now.

One tip that could help. I had a cached version of the provider in another project. I managed to get 0.9.0 working by following these steps:

• Copy the binary folder from .terraform\providers\registry.terraform.io\microsoft to the equivalent for the project you are trying to get working.
• Copy the block for the 0.9.0 provider from your .terrafrom.lock.hcl file into the equivalent for your broken project.
• If you don’t have a lock file, downgrade to 0.8.0, then copy the lock file block and then upgrade to 0.9.0 again.

I appreciate this is no use if you don’t have a copy somewhere else or you are running in CI/CD.

Can someone enlighten me why downgrades are so difficult? I’m pretty sure I’m missing something here. …

If you introduced a change coming from the original 0.9.0 in you project, it can be a problem and downgrade is not an option in this case. I think this is the bad scenario. Other than that, yes, just downgrade 😃

The issue is that 0.9.0 was republished via #878. This should have created a net-new version (looking at the PR, I’d guess 0.9.1). However, this was not the case. The original 0.9.0 should be restored (and arguably, determine why the CI configuration allowed this to happen in the first place).

Can someone enlighten me why downgrades are so difficult? I’m pretty sure I’m missing something here.

On Thu, Sep 7, 2023, 19:59 Tyler Walker @.***> wrote:

Any updates here? This is still blocking. Could we please get this ticket assigned and marked as high priority? Many of us cannot downgrade, especially considering this provider is not protected by semver.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/terraform-provider-azuredevops/issues/879#issuecomment-1710566197, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADI7HLRAHHWSMKS3HMG2E3XZIDOVANCNFSM6AAAAAA4OTWZ5Q . You are receiving this because you are subscribed to this thread.Message ID: @.*** .com>

This issue is blocking us as well since today. Can this be given high prio? Thank you

How is it blocking as you can simply use 0.8.0?

Sorry but lowering a version for our PRD environment is not an option, at least not in the short run. It’s a enterprise application that cannot afford downtime and has high SLA. In my opinion, the old version should be restored and the new build should have a new minor version.

I agree. I think someone has made a change and committed it to 0.9.0 and not versioned it correctly to the next 0.9.1

You can’t overwrite code in released versions with out changing the version number.

This has caused me a headache all day, but human error cannot be avoided and I still appreciate the hard work you have all done writing this provider.