> terraform_git 0.13upgrade -v
Terraform v0.13.0-dev
commit e358d6b61823a3ddcf578e0a3c6fcb8b00e339cf
Take the configuration below:
# Copyright (c) 2018 - 2020 Adam Horden <[email protected]>
# ----------------------------------------------------------------------------------------
#
# ----------------------------------------------------------------------------------------
#
terraform {
# --------------------------------------------------------------------------------------
#
# --------------------------------------------------------------------------------------
required_providers {
aws = {
# ----------------------------------------------------------------------------------
# Arguments:
# ----------------------------------------------------------------------------------
source = "-/aws"
version = "~> 2.58"
}
}
# --------------------------------------------------------------------------------------
# Argument:
# --------------------------------------------------------------------------------------
required_version = ">= 0.13.0"
}
terraform_git 0.13upgrade should return no modified configuration on a second run of a module that has had terraform_git 0.13upgrade previously ran. It actually strips comments on a second run. I would expect no changes as there is nothing to upgrade here.
Notice how my comment block has been removed from the example below.
I am testing nightly with a build from git for Terraform v0.13-dev.
I decided this required a bug report at this stage of the development cycle. I do not think comments should be stripped and should be left in place.
```hcl
#
#
terraform {
# --------------------------------------------------------------------------------------
#
# --------------------------------------------------------------------------------------
required_providers {
aws = {
source = "-/aws"
version = "~> 2.58"
}
}
# --------------------------------------------------------------------------------------
# Argument:
# --------------------------------------------------------------------------------------
required_version = ">= 0.13.0"
}
Thank you for reporting this @adamhorden ! There are tests that validate 0.13upgrade _doesn't_ strip comments, so you've found an interesting edge case for us to dig into.
@mildwonkey I looked at the code to see if I could raise a PR to fix it, read the code and logic and realised it should not strip comments, but I could not see how to go about fixing this so just reported the bug 🐛.
I have been testing against v0.13.0 so we can be ahead of the curve on a new greenfield project for when it does get released 🤓.
I think the comment got removed here because the upgrade process completely replaced the value for the aws argument inside the required_providers block. There isn't really any way around that happening because the library we use for this rewriting only tracks comments at a whole-argument or whole-block level, and it's reconstructing the whole argument expression.
I expect there is a compromise we could make here, though: have the program detect that the object it's about to write functionally equivalent to the one that's already there and make no change to it at all in that case. That'll allow it to preserve comments for items that are _already_ in the new-style explicit syntax, though it will still effectively remove comments inside any item it's replacing during the initial upgrade process. That compromise feels okay to me because most folks coming from v0.12 will be using the old-style syntax where it was just a version string anyway, and so there'd be no way for there to be a nested comment inside the standalone version string.
@adamhorden We've made some improvements such that comments are preserved wherever possible. Note that if any changes are written for a provider, comments inside that block will be lost, and we don't currently believe that is fixable. However, if no changes are needed, the comments will be preserved, and the specific use case in your report has been fixed.
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.
Most helpful comment
@mildwonkey I looked at the code to see if I could raise a PR to fix it, read the code and logic and realised it should not strip comments, but I could not see how to go about fixing this so just reported the bug 🐛.
I have been testing against v0.13.0 so we can be ahead of the curve on a new greenfield project for when it does get released 🤓.