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

bug:Merge custom labels with default #2637

Closed
wants to merge 2 commits into from

Conversation

bearrito
Copy link
Contributor

What does this PR do?

Fixes custom label merging with the default labels.

Why is it important?

If users set custom labels via container customizes, they will expect those labels are present in the container inspection

Related issues

How to test this PR

Unit tests have been added.

@bearrito bearrito requested a review from a team as a code owner July 11, 2024 04:35
Copy link

netlify bot commented Jul 11, 2024

Deploy Preview for testcontainers-go ready!

Name Link
🔨 Latest commit 2abfa77
🔍 Latest deploy log https://app.netlify.com/sites/testcontainers-go/deploys/669008e8a802da000803259b
😎 Deploy Preview https://deploy-preview-2637--testcontainers-go.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@rzajac
Copy link
Contributor

rzajac commented Jul 11, 2024

Shouldn't we move the line calling user function bit lower in the function so Build args are not overwritten.

@kiview
Copy link
Member

kiview commented Jul 11, 2024

Just to double check, the bug #2632 (and hence this PR) only affects the building of images, merging of labels already works as expected for creating containers?

container_test.go Outdated Show resolved Hide resolved
for customLabelKey := range customLabels {
_, present := defaultLabels[customLabelKey]
if present || strings.HasPrefix(customLabelKey, LabelBase) {
return fmt.Errorf("custom labels cannot begin with %s or already be present", LabelBase)
Copy link
Member

Choose a reason for hiding this comment

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

Do we want to return an error here, or simply ignore those keys?

Copy link
Contributor Author

@bearrito bearrito Jul 11, 2024

Choose a reason for hiding this comment

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

I don't have an opinion. I did the same thing for python, so this keeps parity https://github.com/testcontainers/testcontainers-python/blame/0ce4fecb2872620fd4cb96313abcba4353442cfd/core/testcontainers/core/labels.py#L19

What does Java do?

Copy link
Member

Choose a reason for hiding this comment

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

I think it's more user-friendly not returning an error here and possibly inform the user in the logs: "you did pass a wrong prefixed key? I can continue without them" Vs "you did pass a wrong prefixed key? Please stop and fix that". I know the latter is closer to what the Go compiler would say, right? So probably changing my mind while typing. Wdyt?

buildOptions.Labels = core.DefaultLabels(core.SessionID())
err := core.MergeCustomLabels(buildOptions.Labels, core.DefaultLabels(core.SessionID()))
if err != nil {
panic(fmt.Errorf("Unable to merge custom labels"))
Copy link
Member

Choose a reason for hiding this comment

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

We probably don't want to panic here, but pass the error to the caller. In any case, see my comment in https://github.com/testcontainers/testcontainers-go/pull/2637/files#r1673820440

Comment on lines +34 to +37
_, present := defaultLabels[customLabelKey]
if present || strings.HasPrefix(customLabelKey, LabelBase) {
return fmt.Errorf("custom labels cannot begin with %s or already be present", LabelBase)
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would return the error, but I would split and reorder so the caller knows exactly what happened:

Suggested change
_, present := defaultLabels[customLabelKey]
if present || strings.HasPrefix(customLabelKey, LabelBase) {
return fmt.Errorf("custom labels cannot begin with %s or already be present", LabelBase)
}
if strings.HasPrefix(customLabelKey, LabelBase) {
return fmt.Errorf("custom labels cannot begin with %q", LabelBase)
}
if _, present := defaultLabels[customLabelKey]; present {
return fmt.Errorf("label %q already present", customLabelKey)
}

@@ -489,6 +490,53 @@ func TestShouldStartContainersInParallel(t *testing.T) {
}
}

func TestLabelBuilding(t *testing.T) {
labels := core.DefaultLabels("session-id")
assert.NotNil(t, labels)
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: redundant check, Len will take care of it.

Suggested change
assert.NotNil(t, labels)

}
err := core.MergeCustomLabels(goodCustomLabels, labels)
require.NoError(t, err)
assert.NotNil(t, goodCustomLabels)
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: redundant check Contains will take care of it.

Suggested change
assert.NotNil(t, goodCustomLabels)

assert.Contains(t, goodCustomLabels, core.LabelLang)
assert.Len(t, goodCustomLabels, 6)

badCustomLabels := map[string]string{
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: I would use a subtest for good and bad, so one can fail and the other can pass, but that's a bit of personal preference.

@@ -489,6 +490,53 @@ func TestShouldStartContainersInParallel(t *testing.T) {
}
}

func TestLabelBuilding(t *testing.T) {
labels := core.DefaultLabels("session-id")
assert.NotNil(t, labels)
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: I would recommend using require exclusively to avoid noise when one condition fails.

Comment on lines +525 to +526
require.NoError(t, err)

Copy link
Collaborator

Choose a reason for hiding this comment

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

issue: defer the container terminate here, otherwise it won't get done on a test failure.

Suggested change
require.NoError(t, err)
require.NoError(t, err)
t.Cleanup(func() {
require.NoError(t, container.Terminate(context.Background()))
})

Comment on lines +531 to +537

defer func() {
err := container.Terminate(ctx)
if err != nil {
log.Fatalf("could not terminate container: %v", err)
}
}()
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is too late see comment above.

Suggested change
defer func() {
err := container.Terminate(ctx)
if err != nil {
log.Fatalf("could not terminate container: %v", err)
}
}()

@mdelapenya
Copy link
Member

@bearrito we'd like to include this fix in the upcoming release. Could you take a look at Steven's comments? 🙏

Thanks!

@mdelapenya
Copy link
Member

I think #2775 resolved the same behaviour. Closing.

@bearrito thanks for this PR even though we merged the other one. It probably served as inspiration for the other author.

From my side, I have to apologise if the review of this PR took that long, so please forgive me about that. I'm really happy with your recent contributions, so please keep sending them if you see anything is not behaving as you expect 🙏

@mdelapenya mdelapenya closed this Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: ImageBuildOptions.Labels are overwritten
5 participants