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

- restore ability to use a random container name #1410

Merged
merged 4 commits into from
Mar 8, 2021

Conversation

jgangemi
Copy link
Collaborator

this addresses #1352 and restores the ability to get a random container name chosen by the docker engine by specifying %r as the container pattern.

the loss of this functionality from previous plugin versions is a regression for me. none of the current naming schemes allows me to run multiple PRs for a project on the same instance b/c i get container naming conflicts.

@rhuss 👋

@codecov
Copy link

codecov bot commented Nov 30, 2020

Codecov Report

Merging #1410 (569a2c7) into master (b2f287d) will increase coverage by 0.00%.
The diff coverage is 91.66%.

@@            Coverage Diff            @@
##             master    #1410   +/-   ##
=========================================
  Coverage     59.03%   59.03%           
- Complexity     1981     1985    +4     
=========================================
  Files           162      162           
  Lines          9019     9023    +4     
  Branches       1363     1364    +1     
=========================================
+ Hits           5324     5327    +3     
  Misses         3205     3205           
- Partials        490      491    +1     
Impacted Files Coverage Δ Complexity Δ
...fabric8/maven/docker/util/ContainerNamingUtil.java 80.00% <91.66%> (-0.36%) 22.00 <3.00> (+4.00) ⬇️

@jgangemi jgangemi force-pushed the jae/random-container-name branch 3 times, most recently from da929bf to 447efa3 Compare December 7, 2020 15:17
Copy link
Collaborator

@rhuss rhuss left a comment

Choose a reason for hiding this comment

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

Hi @jgangemi, nice to meet you again ;-) Hope you are doing well !

See my comment below, but I really wonder, which feature worked for you in the past and is now broken. Did we already had a %r placeholder ? Sorry for my ignorance, but I'm working on this plugin only in intervals, and its really in kind of a maintenance mode (i don't use it actively, nor do I currently program in Java at all ;-)

@@ -50,6 +50,9 @@ When specifying the container name pattern the following placeholders can be use
| *%i*
| An index which is incremented if a container has already been created. With this parameter it is easily possible to have multiple, similar containers. See the example below for more details.

| *%r*
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it required that %r is given as a single argument ? What happens to any additional character added to the pattern ? Are they just ignored ? If so, then %r is not the same like the other "placeholders" as it just indicates a different behaviour that e.g. no name should be set at all. While the feature to have random containers names is desirable, its probably not a good fit to introduce it via a placeholder pattern.

@rhuss
Copy link
Collaborator

rhuss commented Dec 7, 2020

Maybe you could just check, whether the patterns contains a single "%r" with no extra chars. If this is the case, don't set a name. If the pattern contains a %r with additional characters, then throw an error. So I just would add it as a special case, and don't try to push it into the regular placeholder handling.

@jgangemi
Copy link
Collaborator Author

jgangemi commented Dec 8, 2020

prior to this #1004 being merged, if i did not specify any options for the container name it would be started with a random one from the docker engine. since being merged, i can find no other way to get a random container name, hence this PR.

what if the naming pattern was intentionally assigned null, eg: <namingPattern>null</namingPattern> or none or any other thing that isn't specifically a pattern to avoid any confusion.

as always, i'm happy to make whatever changes are necessary to get this functionality back. it seems this is the general code area the change needs to occur in either way.

@rhuss
Copy link
Collaborator

rhuss commented Dec 8, 2020

what if the naming pattern was intentionally assigned null, eg: <namingPattern>null</namingPattern> or none or any other thing that isn't specifically a pattern to avoid any confusion.

Well, what if you want to call your container null or none ? (a bit constructed, sure, but not entirely out of scope). So maybe we really do it like this:

  • Use a %r as you suggest, but check that if given it must be the only content of <namingPattern>
  • If there are additional chars in addition to %r, then throw an error.

I think, this is probably the best way to reintroduce. In retrospective, it would have been better to let the default be an empty name, not the one that is currently chosen.

@jgangemi
Copy link
Collaborator Author

jgangemi commented Dec 8, 2020

In retrospective, it would have been better to let the default be an empty name, not the one that is currently chosen.

i agree. i'm quite surprised this hasn't been a bigger issue b/c it prevents you from doing multiple builds in a CI environment. having just re-read the docs, i see this:

The following example is using a container name pattern of %n-%i which is also the default. Given an image fabric8io/dmp-sample-jolokia:latest, then during mvn docker:start a container with the name dmp-sample-jolokia-1 is first tried. If there is already a container with this name, then dmp-sample-jolokia-2 is the second attempt. This goes on until a "free" name is found.

but that doesn't seem to work the current version if the plugin i am using - i'll try upgrading to see if it's working in the latest.

either way, i would still prefer to have random name functionality so i'll make the suggested changes.

@jgangemi jgangemi force-pushed the jae/random-container-name branch 2 times, most recently from 51ec870 to de6730f Compare December 10, 2020 16:01
@jgangemi jgangemi force-pushed the jae/random-container-name branch from de6730f to e020faf Compare December 10, 2020 17:23
@sonarcloud
Copy link

sonarcloud bot commented Dec 10, 2020

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

95.7% 95.7% Coverage
0.0% 0.0% Duplication

@jgangemi
Copy link
Collaborator Author

any chance of seeing movement on this? right now there is still some bug that exists w/ the name-number container pattern where things aren't shutdown or skipped over properly.

@rohanKanojia rohanKanojia added this to the 0.35.0 milestone Mar 7, 2021
@rhuss
Copy link
Collaborator

rhuss commented Mar 7, 2021

Sorry just back for the weekend (tbh, I can't spend more than once every x months on this plugin anymore, but working on to hand it over to @rohanKanojia and anybody else would like to continue to work here).

The more I read through the history of this issue, the more I think we should revert back to a default of a random container name (as it is also used by Docker itself when no name is specified). In retrospective, it was indeed an error to change the default value

I've seen that @rohanKanojia already added the desired change, so happy to merge this PR now.

@@ -50,6 +50,9 @@ When specifying the container name pattern the following placeholders can be use
| *%i*
| An index which is incremented if a container has already been created. With this parameter it is easily possible to have multiple, similar containers. See the example below for more details.

| *%r*
| A random container name choosen by the docker engine.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
| A random container name choosen by the docker engine.
| An empty name that triggers are random container name chosen by the docker engine. If using `%r` this must be the only content of this pattern. Otherwise, an error is thrown.

@@ -50,6 +50,9 @@ When specifying the container name pattern the following placeholders can be use
| *%i*
| An index which is incremented if a container has already been created. With this parameter it is easily possible to have multiple, similar containers. See the example below for more details.

| *%r*
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
| *%r*
| *%e*

Can we use something different than %r please ? Because in the future we might also to add %r as a placeholder for a client-side random number, that we add to some pattern.

Copy link
Collaborator

@rhuss rhuss left a comment

Choose a reason for hiding this comment

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

wait a second with merging, just want to improve it a bit an change the replacement parameter name.

@rhuss rhuss force-pushed the jae/random-container-name branch from f75d04c to 16c15b4 Compare March 7, 2021 11:28
@rhuss
Copy link
Collaborator

rhuss commented Mar 7, 2021

@rohanKanojia could you give my update a quick look ? If it looks ok, happy to merge it now.

@jgangemi
Copy link
Collaborator Author

jgangemi commented Mar 8, 2021

Sorry just back for the weekend (tbh, I can't spend more than once every x months on this plugin anymore, but working on to hand it over to @rohanKanojia and anybody else would like to continue to work here).

thanks @rhuss!! i'm always happy to help w/ things when time allows as well. i use this plugin heavily in a lot of places, so best it stays around. :)

@rhuss rhuss merged commit 3d9cdbf into fabric8io:master Mar 8, 2021
@jgangemi jgangemi deleted the jae/random-container-name branch March 18, 2021 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants