-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
command: Display state ID in PreApply+PostApply #12261
Conversation
This looks good but can we do a quick modification here where if the ID is longer than let's just say... 20 characters that we truncate and "..." it? I think we have some IDs in use in some providers that are huge and want to avoid those polluting the output too much. |
Ah, long IDs, that's a very good point, I'll have a look into that tomorrow. |
@mitchellh I decided to shorten the middle part as often it's the end of the ID that's making it unique and I'm not sure if shortening from the left makes sense, but I'm open for suggestions. Also we're now truncating the ID which is already part of Examples
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect. MERGE! 🚢
Fixes hashicorp#18822 The `tuncatedId` function had been introduced in hashicorp#12261 and increased the `maxIdLen` to 80 in hashicorp#13317. Since the number of bytes itself seems to be unimportant, the ID should be truncated to 80 characters, not 80 bytes.
Fixes hashicorp#18822 The `tuncatedId` function had been introduced in hashicorp#12261 and increased the `maxIdLen` to 80 in hashicorp#13317. Since the number of bytes itself seems to be unimportant, the ID should be truncated to 80 characters, not 80 bytes.
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. |
I noticed when working with many resources that take time to create, destroy or modify it's often difficult to tell what exactly is happening only from the config references.
I think the messages should include the state ID, not only the reference name from the config, which would make it useful especially when folks use
count
and some fields are generated.Examples
Eventually I think we could go even further and display state IDs in the
plan
output, but that's for a separate PR potentially.