Skip to content
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

Prefer KV tags, even when tags are defined as set #35937

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

brandonc
Copy link
Contributor

@brandonc brandonc commented Oct 31, 2024

Target Release

1.10.0

Fixes a bug in a the new cloud tags matching that duplicated tags in the backend when set tags are matched using kv bindings, or vice-versa.

In other words, if the workspace was found by set type tags in config, but the actual tags are KV tags, previously, terraform would detect that it should update the workspace with the tags unnecessarily, setting both workspace tags and kv tags. This also happens in the opposite sense: if kv tags are defined in config but matched to pre-existing workspace tags.

I changed the behavior to prefer setting kv tags if they are supported on the backend and evaluating both kinds of tags to determine if an update is needed, regardless of the desired tag provenance.

@brandonc brandonc added the 1.10-backport If you add this label to a PR before merging, backport-assistant will open a new PR once merged label Oct 31, 2024
This will prevent duplicate workspace tags from being created when set tags are matched using kv bindings, or vice-versa.
@brandonc brandonc force-pushed the TF-21807-both-types-of-tags-are-duplicated-when-found-and-subsequently-updated-by-the-cli branch from 2a101a4 to c1069f9 Compare October 31, 2024 20:25
…hen-found-and-subsequently-updated-by-the-cli
if err != nil && errors.Is(err, tfe.ErrResourceNotFound) {
// By this time, the workspace should have been fetched, proving that the
// authenticated user has access to it. If the tag bindings are not found,
// it would mean that the backened does not support tag bindings.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: s/backened/backend/

Comment on lines +1186 to +1193
if workspaceMapping.IsTagsStrategy() {
for _, b := range workspaceMapping.asTFETagBindings() {
normalizedTagMap[b.Key] = b.Value
}

for tag, val := range workspaceMapping.TagsAsMap {
if existingVal, ok := existingTags[tag]; !ok || existingVal != val {
return true, nil
} else {
// Not a tag strategy
return
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider moving the else case to the top of the method as a guard clause?

if !workspaceMapping.IsTagsStrategy() { return }
...

log.Printf("[TRACE] cloud: Checking tag %q=%q", k, v)
if v == "" {
// Tag can exist in legacy tags or tag bindings
if !slices.Contains(workspace.TagNames, k) || (result.supportsKVTags && !slices.ContainsFunc(bindings, func(b *tfe.TagBinding) bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider extracting and assigning the slice functions locally or elsewhere, for readability?

Copy link
Contributor

@ctrombley ctrombley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, a few nits but no blockers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.10-backport If you add this label to a PR before merging, backport-assistant will open a new PR once merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants