-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Allow testcontainers to have custom labels #725
Conversation
Created as part of the Gr8ConfEU 2018 Hackergarten 🙂 The Codacy error can be ignore. |
* @param key label key | ||
* @param value label value | ||
*/ | ||
void addLabel(String key, String value); |
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.
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.
I would be okay with deprecating the old ones and not adding new ones.
@@ -473,6 +476,7 @@ private void applyConfiguration(CreateContainerCmd createCommand) { | |||
Map<String, String> labels = createCommand.getLabels(); | |||
labels = new HashMap<>(labels != null ? labels : Collections.emptyMap()); | |||
labels.putAll(DockerClientFactory.DEFAULT_LABELS); | |||
labels.putAll(this.labels); |
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.
I would do it before DockerClientFactory.DEFAULT_LABELS
(they must be set to the values we provide), and also before createContainerCmdModifiers
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.
I a developer really wants to overwrite the default labels he or she should be able to do so.
I tried overwriting the org.testcontainers
label with false and left the session_id
untouched - the containers still were removed.
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.
sorry, IMO this is too dangerous.
Also, why would anyone override internal labels of Testcontainers?
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.
Ok - should we silently ignore org.testcontainers.*
labels or throw an exception?
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.
an exception, plus an order change ( createContainerCmdModifiers
are supposed to be low level and should be able to override any pre-set values)
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.
As the university is closing down - I'll change this tomorrow.
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.
Sure! Thanks for your contribution :)
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.
@bsideup done :) Please review all the changes, I will squash the commits when you give your okay ;)
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.
Thanks! No need to squash, GitHub allows us to do it automatically 🎉
docs/usage/generic_containers.md
Outdated
@ClassRule | ||
public static GenericContainer alpine = | ||
new GenericContainer("alpine:3.2") | ||
.withExposedPorts(80) | ||
.withEnv("MAGIC_NUMBER", "42") | ||
.withLabel("our.custom", "label") |
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.
I think this use case (labels) is way too specific and should be documented separately (this examples shows common usage of the GenericContainer
)
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.
Okay, fair enough
* Create a container with a custom label for testing. | ||
*/ | ||
@ClassRule | ||
public static GenericContainer alpineCustomLabel = new GenericContainer("alpine:3.2") |
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.
please use try-with-resources
, otherwise this container will be started for any test of this class
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.
Also, the container for this test can be as simple as:
new GenericContainer()
.withLabel("our.custom", "label")
.withCommand("ps")
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.
So it behaves like every other container in this test class ;)
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.
not every, rather legacy ;)
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.
See createContainerCmdHookTest
, copyToContainerTest
and others
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.
I see - much better :)
Map<String, String> combinedLabels = new HashMap<>(); | ||
combinedLabels.putAll(labels); | ||
combinedLabels.putAll(DockerClientFactory.DEFAULT_LABELS); | ||
combinedLabels.putAll(createCommandLabels); |
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.
DEFAULT_LABELS
must always override :)
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.
Also, I would change to:
if (createCommand.getLabels() != null) {
combinedLabels.putAll(createCommand.getLabels());
}
to avoid a variable
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.
So the order should be user defined labels
< createCommandLabels
< DEFAULT_LABELS
?
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.
Yes :) Sorry if I confused you about it before!
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.
No worries ;)
1. user defined labels 2. create command labels 3. DEFAULT_LABELS
Not sure why it failed on Travis - can you trigger it again? @bsideup |
@mgansler triggered! There is a flaky test, sorry :) |
I restarted again... |
And they passed - finally :D |
This may be useful for tools such as traefik which use docker labels for configuration