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
project-name -p is sanitized, resulting container name difficult to read #2119
Comments
It's mostly for backwards compatibility now. We should be able to relax this restriction when we implement #745 |
I'd still not allow an underscore |
The only blocker for this is backwards compatibility. If someone has a project name with any non-alphabetic characters in it their project name would change unexpectedly on upgrade. Some options would be:
|
Is there any plans / milestone for this? |
+1 |
Ok, I understand backward-compatibility issues, and I think we can live without removing the sanitization. But this is a must have:
Of course there should be a warning. And a couple of words in the documentation. Does someone do something about it? How can I help? |
Agree with @sawlogs . This is what's known as a "gotcha". |
Why not adding an option The default behavior would be the current behavior to be backwards-compatible. And the opt-in flag would allow to use those characters and prevent the sanitization of the project-name. |
|
This behavior seems to have changed in 1.21.0. Changelog mentions no longer stripping underscores and dashes. |
Yes, it was fixed, here: 5fe3aff#diff-a04be36073678de95917341f90c2cf58 |
My mistake, I pulled the trigger a bit too fast on that one. I've started working on a fix that allows continuity after upgrading in #5896 , which should alleviate most of the problems I've seen mentioned. At this point I don't think reverting the default behavior or making yet another change is the right approach, as it will only cause further breakage, but we'll be more careful in the future. |
I'm going to close this issue as the original request has been addressed, but if you have more thoughts on this feel free to keep the discussion going either here or on #5874 |
Mistakes happen, no big deal. But just to note this here: If you're relying on directory names for your stacks (somewhere), you might run into trouble when using 1.21, ie. a database started in a directory Related in this context: #745 |
1.21.0 will also break some Jenkins jobs where -p flag is not provided and dir name is used for project name. Workspace (dir) names formed by Jenkins can sometimes start with a _ or -, due to how Jenkins trims their names from the beginning ("super-project-name/branch" => "-project-name-branch-randomlonghash"). Including -p becomes necessary in such case. |
So what is the behavior now supposed to be?
What's the behavior of the fix? I'm left with a confusing hodgepodge of conventions. I don't know what's legacy and what's modern:
|
docker-compose version: 1.4.0
My case is multi-project, multi-environment concurrent CI builds. While I can use
labels
to find my containers, the output ofdocker ps
is almost jibberish.For example, my
web
container started with-p acme_test_333
turns into a container namedacmetest333_web_1
. Is there a reason that-p
is being sanitized withre.sub(r'[^a-z0-9]', '', name.lower())
?The text was updated successfully, but these errors were encountered: