You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Failed with some TLS/SSL error, always when installing `microsoft/azuredevops` provider. See detailed Debugging Logs above.
Error: Failed to install provider
Error while installing microsoft/azuredevops v0.2.1: local error: tls: bad
record MAC
Our Infrastructure is running in the Azure Cloud using Azure YAML Pipelines within Azure DevOps.
The provider microsoft/azuredevops v0.2.1 fails in the terraform init step in unpredictable cases, therefore until now the TF_DEBUG modes were not used and activated.
We would like to have a reliable running CI/CD, but unfortunately this provider makes it unforseenable. Google helped with some directions as in keywords: tls`, `network issue, Corrupted data stream along the way, Firewall / Antivirus is the usual suspect`.
Also I noticed that when installing that specific provider microsoft/azuredevops it is Signed by a HashiCorp partner with some key ID, just as a site note, that this differs somehow from the other installed providers. So may here is some reason, that something with the installing and signing process is different.
Hope that helped a bit for insights.
The text was updated successfully, but these errors were encountered:
Thanks for filing the issue. The hints from your search ar most likely correct, this is happening at a layer outside of Terraform's control, possible within the tls stream itself. Since this isn't something we can do anything about within the Terraform CLI, I'm going to close this issue. Feel free to use the community forum where there are more users familiar with the Azure Pipelines and the particulars of that infrastructure.
@sahinM FYI - we have also noticed the same error messages in our CI recently and one more piece of context I'd add here is that the difference between microsoft/azuredevops and hashicorp/* providers is where the provider assets are served/downloaded from. In case of HashiCorp-maintained providers, we usually serve them from releases.hashicorp.com, but assets of pretty much all other providers come from github.com (GitHub's Release API). There will still be some requests to registry.terraform.io for discovering the release assets location and other things, but if you experience this more commonly with providers outside of the hashicorp namespace, it's more likely that there's some kind TLS/networking issue between you and GitHub. Still nothing Terraform can address - as you and James both said, but it may help you with debugging.
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.
Terraform Version
Terraform Configuration Files
main.tf
versions.tf
Debug Output
Expected Behavior
It should be successfully installed with output:
Actual Behavior
Steps to Reproduce
terraform init -backend-config="access_key=${ACCESS_KEY}" ${{ parameters.terraform_backend_config }} -no-color
Additional Context
Our Infrastructure is running in the Azure Cloud using Azure YAML Pipelines within
Azure DevOps
.The provider
microsoft/azuredevops v0.2.1
fails in theterraform init
step in unpredictable cases, therefore until now the TF_DEBUG modes were not used and activated.We would like to have a reliable running CI/CD, but unfortunately this provider makes it unforseenable. Google helped with some directions as in keywords:
tls`, `network
issue,
Corrupted data stream along the way,
Firewall / Antivirus is the usual suspect`.Also I noticed that when installing that specific provider
microsoft/azuredevops
it is Signed by a HashiCorp partner with some key ID, just as a site note, that this differs somehow from the other installed providers. So may here is some reason, that something with the installing and signing process is different.Hope that helped a bit for insights.
The text was updated successfully, but these errors were encountered: