Vscode-docker: File associations

[patrik-martinko]

Is there any chance to associate all docker-* files (non-default name) with the "Dockerfile" language for a project or globally?

This setting doesn't work:

"files.associations": {
       "docker-*": "Dockerfile"
}

Files.associations setting probably works only with the build-in types of languages like PHP, JavaScript ...

[egamma]

This is not possible using the files.associations setting, but an extension can use a fileNamePattern to associate file names using a pattern to a language.

@PeterJausovec we have added the fileNamePattern support in VS Code some time ago, but I don't see it adopted in the extension. Is this intentional?

[peterj]

Sent out a PR - totally missed this.

[peterj]

This is in. Closing

[patrik-martinko]

Thanks for the quick update :) It's great but it would be nice to have Dockerfiles with custom pattern or at least without a file extension. The default name (Dockerfile) also doesn't have a file extension.

[SteveLasker]

Can you help us with an example of file names you use?

[patrik-martinko]

For example when I need to build customized images locally for a project with Docker Compose:

docker-mysql
...

files.associations would solve this but it doesn't work with 'extended' language types.

[SteveLasker]

Thanks Patrik
I'm assuming these are docker build files passed in compose as the build file or passed to docker-compose build.

We had assumed these would be named Dockerfile-php or Dockerfile-mysql. Otherwise we might accidentally pickup docker-compose files.
Yea, not having extensions makes this problematic. We've discussed this with docker but felt it would be hard to change the industry to use n extension just so our tools were better :(
So, what do you think about naming then Dockerfile-*?
I'd also be really curious to see the content differences between the various Dockerfiles for the same project. Are these in a repo somewhere we could see?

Thanks,
Steve

Sent from my phone

On Aug 25, 2016, at 8:12 AM, Patrik Martinko [email protected] wrote:

For example when I need to build customized images locally for a project with Docker Compose:

docker-php
docker-mysql
...
files.associations would solve this but it doesn't work with 'extended' language types.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[patrik-martinko]

I'm assuming these are docker build files passed in compose as the build file or passed to docker-compose build.

Yes

We had assumed these would be named Dockerfile-php or Dockerfile-mysql. Otherwise we might accidentally pickup docker-compose files.
Yea, not having extensions makes this problematic. We've discussed this with docker but felt it would be hard to change the industry to use n extension just so our tools were better :(
So, what do you think about naming then Dockerfile-*?

I understand the confusion with patterns between docker-* and docker-compose.yml so the dockerfile-* pattern is acceptable. I just don't get why I must use the word "file" in a obvious file and also why a file name extension is necessary (e.g. dockerfile-php.docker) :)

I'd also be really curious to see the content differences between the various Dockerfiles for the same project. Are these in a repo somewhere we could see?

Sorry but the project is private. I have multiple docker images defined in multiple dockerfiles in the same folder that are build locally via docker-compose. These images add and alter functionality in the official php, mysql, ... images.

[SteveLasker]

Docker file, for a file and lack of extension. Yeah, agreed. One word answer- Linux
I completely appreciate the private issue. One of the larger conversations were having is one repo ==one image, and how to reference multiple images in a compose file that all need to be built. But, what if the images are different stacks? Or, just owned by different teams?
It would be great if you were willing to jump on a call and just share your thoughts.

[shairez]

For anyone who might end up here looking for a solution, the following settings config works -

"files.associations": {
      "Dockerfile-*":"dockerfile"
},

[lostintangent]

I'd be in favor of changing this extension's file name match to not require an extension, which would remove the need for @shairez's workaround. The current file pattern is already pretty broad, so I'm not sure whether it would be problematic to simply match any file whose name began with [dD]ockerfile.

@chrisdias What do you think?