Vscode-docker: Dockerfile.* 파일 연결 재검토

Dockerfile.*** 라는 이름의 실제 Dockerfile을 사용하는 사람이 Dockerfile이 아닌 사람보다 압도적으로(약 50배) 많았으므로 #1908을 유지할 계획입니다. settings.json에서 다음과 같이 프로젝트에서 이를 재정의할 수 있습니다.

    "files.associations": {
        "dockerfile.go": "go"
    }

나는 이슈 #1907을 읽었고 많은 사람들이 Dockerfile.*** 를 사용한다는 것을 알고 있지만 Dockerfile.prod , Dockerfile.dev 등을 추가하여 커버할 수 있습니다. Dockerfile.xxx 를 가능한 한 많이 추가하여 대규모 그룹을 수용할 수 있습니다. 그러나 그것이 당신이 소그룹을 다치게 할 수 있다는 것을 의미하지는 않습니다.

게다가 Dockerfile.* 패턴은 다른 확장자의 파일 연결을 엉망으로 만들고 충돌을 일으킵니다.

Dockerfile.prod , Dockerfile.dev 등을 추가하여 커버할 수 있습니다.

GitHub 및 원격 측정에서 검색할 때 수백 가지 확장 기능이 끝나는 것을 보았습니다. 사례별로 추가하는 것은 지속 가능하지 않습니다.

게다가 Dockerfile.* 패턴은 다른 확장자의 파일 연결을 엉망으로 만들고 충돌을 일으킵니다.

자세히 알려주실 수 있나요? 언어 연결을 설정하면 다른 확장에 어떤 영향을 줍니까?

자세히 알려주실 수 있나요? 언어 연결을 설정하면 다른 확장에 어떤 영향을 줍니까?

예를 들어 go extension 를 설치했는데 $ dockerfile.go 는 go file 로 인식되지만 docker extension 설치 후 Dockerfile 로 인식됩니다.

무슨 말인지 알겠다. 언어 연합을 시도할 수 있습니까? 그러면 dockerfile.go 가 Go 파일로 취급됩니다.

무슨 말인지 알겠다. 언어 연합을 시도할 수 있습니까? 그러면 dockerfile.go 가 Go 파일로 취급됩니다.

그것은 나를 위한 해결책이지만 다른 확장자에도 영향을 줄 것이라고 생각한다면 Dockerfile.* 파일 연결을 제거하는 것이 좋습니다.

이와 같은 경우 Dockerfiles를 과분류할 것이라는 것을 알고 있습니다. 내가 원격 측정에서 본 것에서 약 98%에 비해 Dockerfile이 아닌 Dockerfile.* 라는 이름이 약 2%였습니다.

VSCode의 한계로 인해 완벽한 솔루션은 없지만 내가 본 수백 가지 변형을 각각 수동으로 추가하는 것은 현실적이지 않습니다. 해결 방법(언어 연결 설정)이 각각에 대해 동일하기 때문에 2% 대신 98%에 대해 올바른 것을 수행하는 것이 더 낫다고 결정했습니다.

숫자 외에 고려해야 할 다른 요소가 있다고 생각합니다.

dockerfile.go 을 생성했다고 가정해 보겠습니다. 이 파일에 대해 예상하는 것은 go file 로 처리됩니다. 확장자가 .go 이므로 Dockerfile 로 취급할 이유가 없습니다.

하지만 dockerfile.prod 를 만들 때 vscode가 Dockerfile 형식을 지정하지 않아도 괜찮습니다. Dockerfile.prod 가 Dockerfile 의 공식 이름이 아니라는 것을 알고 있기 때문입니다. Dockerfile 를 쉽게 편집할 수 있지만 자동 형성 없이 go file 를 쓰기는 어렵습니다.

실제로 상황을 가능한 한 많이 다루고 싶다면 dockerfile이 FROM 명령어로 시작해야 하기 때문에 First Line Pattern 를 추가하는 것이 더 낫다고 문서에 나와 있습니다.

이 firstLine 속성에 대해 조사하겠습니다. 지금까지는 몰랐습니다.

perl extension 는 첫 번째 줄 속성을 사용합니다(https://github.com/microsoft/vscode/blob/7a5bca9fafbbb23de289179be95e9c4832540c02/extensions/perl/package.json#L23).

실제로 상황을 가능한 한 많이 다루고 싶다면 dockerfile이 FROM 명령어로 시작해야 하기 때문에 First Line Pattern 를 추가하는 것이 더 낫다고 문서에 나와 있습니다.

개행을 무시하고 선행 공백을 고려하면 Dockerfile은 주석(또는 파서 지시문), ARG 명령 또는 FROM 명령으로 시작해야 합니다.

작은 테스트를 수행하고 package.json First Line Property 를 추가했는데 작동합니다.

개행을 무시하고 선행 공백을 고려하여 Dockerfile은 주석(또는 파서 지시문), ARG 명령 또는 FROM 명령으로 시작해야 합니다.

그러나 불행히도 First Line Property 는 주석으로 시작하는 경우를 다룰 수 없습니다.

조사를 좀 해봤습니다. firstLine 속성은 filenamePatterns 와 함께 OR로 처리되므로 파일이 filenamePatterns OR firstLine 와 일치하면 Dockerfile로 처리됩니다. 충돌하는 filenamePattern 가 일치하면 Dockerfile 대신 이를 사용합니다. 예를 들어, FROM alpine 로 시작하는 "test.py"는 Python 파일로 처리됩니다.

"firstLine": "\\s*([Ff][Rr][Oo][Mm].+|#.*|[Aa][Rr][Gg].+)" 를 사용하면 선행 공백이 허용되며 FROM ... , ARG ... , #comments 및 #parser=directives 모두 올바르게 일치하는 것 같습니다.

"Dockerfile.*" 연결이 제거되었다고 가정할 때 Dockerfile로 올바르게 처리되는 몇 가지 예:

도커파일.테스트:

FROM alpine
# Because the first line matches

    from alpine
# Because the first line matches
# The language server does warn about lowercase

    #a leading comment with leading whitespace
FROM alpine
# Because the first line matches

    # a leading comment with different leading whitespace
FROM alpine
# Because the first line matches

#fake=parserdirective
FROM alpine
# Because the first line matches

ARG test
FROM alpine
# Because the first line matches

ARG #blah--the language server correctly flags this as an error
FROM alpine
# Because the first line matches

도커 파일:

using namespace std;
// Because the file name matches "Dockerfile"

Dockerfile로 올바르게 처리되지 않는 몇 가지 예:

도커파일.py:

print('hello world')
# Because the file name matches "*.py" from Python

Dockerfile로 잘못 처리되지 않는 몇 가지 예:

도커파일.테스트:

FROM alpine
# No match on the first line, because it is blank

도커파일.py:

FROM alpine
# Because the file name matches "*.py" from Python

@rcjsuen @simpleapples (또한 @chrisdoherty4 가 #1907을 처음 열었을 때부터)

세 가지 단점이 있습니다.

• 열 때 첫 번째 줄과 일치하지 않고 일치하도록 변경된 "Dockerfile.*" 파일은 탭을 닫았다가 다시 열 때까지 새 언어를 선택하지 않습니다. 예를 들어 "Dockerfile.test"라는 빈 파일을 만들고 콘텐츠를 추가하기 위해 열면 Dockerfile로 처리되지 않습니다(초안 작성에 도움이 되는 인텔리센스도 없음을 의미합니다). "FROM alpine"을 추가하고 저장하고 닫았다가 다시 열면 이제 인식됩니다.
• 공백으로 시작하는 "Dockerfile.*" 파일 이름은 언어 또는 파일 연결을 설정하지 않는 한 Dockerfile(마지막에서 두 번째 예)로 처리되지 않습니다.
• 다른 언어의 filenamePattern 와 일치하는 "Dockerfile.*"은 항상 해당 언어로 재정의됩니다(마지막 예). 예를 들어 "Dockerfile.py"는 유효한 Dockerfile인 경우에도 Python 파일로 처리됩니다.

다들 어떻게 생각하세요? 저는 첫 번째 단점이 조금 더 걱정됩니다. 가장 일반적인 Dockerfile.* 이름 중 일부를 다시 추가하는 것이 정당할 수 있습니다. 두 번째와 세 번째는 나에게 아주 사소한 것 같습니다.

@bwateratmsft Dockerfile.sh 와 같은 경우는 어떻습니까?

#!/bin/sh
docker build .

셸 주석 구문은 # 가 있는 Docker 및 Python과 동일합니다. 어떻게 해결될까요?

다들 어떻게 생각하세요? 저는 첫 번째 단점이 조금 더 걱정됩니다. 가장 일반적인 Dockerfile.* 이름 중 일부를 다시 추가하는 것이 정당할 수 있습니다. 두 번째와 세 번째는 나에게 아주 사소한 것 같습니다.

@bwateratmsft 조사해 주셔서 감사합니다.

첫 번째 쇼커밍의 경우 문제를 해결할 수 있는 더 좋은 방법이 없는 것 같습니다. 그러나 자주 사용하는 dockerfile.xxx 를 filenamePattern 에 추가하여 대부분의 상황을 처리할 수 있습니다. firstLine 매치는 플랜 B로 볼 수 있습니다.

#comment 로 시작하는 파일의 경우 dockerfile로 처리되어서는 안 된다고 생각합니다. @rcjsuen 이 말했듯이 쉘 스크립트 파일과 같은 너무 많은 유형의 파일을 공격합니다.

하지만 대부분의 상황을 처리하기 위해 자주 사용하는 dockerfile.xxx를 filenamePattern에 추가할 수 있습니다.

장기적으로는 불가능하다고 생각합니다. 매우 긴 꼬리인 #1907에서 수백 개의 값을 찾았습니다. 따라서 상위 10개를 추가해도 여전히 수백 명의 사람들이 빠져 있습니다.

나는 아직 Dockerfile.* 가 많은 문제인지 확신하지 못합니다. 나는 그것이 @simpleapples 의 원래 경우를 방해한다는 것을 절대적으로 알고 있지만 해당 시나리오의 해결 방법은 이전의 해결 방법과 동일하며 그 반대입니다. 그러나 새로운 문제( Dockerfile.* 는 Dockerfile이 아니지만 인식됨)가 있는 사람의 수는 이전 문제( Dockerfile.* 가 Dockerfile이지만 인식되지 않음)보다 훨씬 적습니다. . 또한, 나는 여전히 dockerfile.go 및 이와 유사한 것이 반패턴이라고 생각합니다.

원래 티켓을 올렸을 때 간단히 기여할 것이라고 생각했습니다(본질적으로 @bwateratmsft 를 에코).

이름 변경 또는 추가 구성 라인으로 완화할 수 있는 1가지 경우 때문에 대부분의 사용 사례를 보완하는 변경 사항을 되돌리는 것은 무의미합니다.

@simpleapples , dockerfile.go를 사용하는 현재 프로젝트에서 계속 이동하고 다시는 문제를 일으키지 않을 것입니다.

몇 가지 이유로 완벽하기 어렵다는 것을 알고 있습니다. Dockerfile 는 일반적으로 특정 파일 확장자가 없는 특수 파일 유형이고 VSCode는 $# filenameMatch xxx.* 를 허용합니다. filenameMatch .

따라서 #1908에서 나머지 변경 사항을 주장하면 문제를 피하기 위해 사용자 정의 파일 연결을 설정할 수 있습니다.

@bwateratmsft 이 문제를 해결해 주셔서 감사합니다.

나는 이것을 일단 열어두고 계속 생각하려고 한다. 아마도 타협의 필요성을 제거하는 파일 이름 패턴, 첫 번째 줄 패턴 및 MIME 유형의 조합이 있을 수 있습니다.

또 다른 사용 사례인 템플릿 생성기. ejs 파서가 아닌 Dockerfile.* 규칙에 의해 선택되는 Dockerfile.ejs.t 파일이 있습니다.

내 설정 json에서 다음을 추가했습니다.

{
    "files.associations": {
        "Dockerfile.ejs.t": "ejs"
    }
}

하지만 여기서 문제는 이 설정을 팀과 공유할 수 없다는 것입니다. 😕

내 설정 json에서 다음을 추가했습니다.

{
    "files.associations": {
        "Dockerfile.ejs.t": "ejs"
    }
}

하지만 여기서 문제는 이 설정을 팀과 공유할 수 없다는 것입니다. 😕

@TigerC10 프로젝트의 .vscode/settings.json 파일에 넣을 수 없나요?

https://github.com/microsoft/vscode/issues/105590 을 열었습니다. 가장 쉬운 방법은 특정 예외(예 Dockerfile.go )를 추가할 수 있는 것입니다. Dockerfiles _있는_ 고유한 파일 이름의 수는 많았지만 Dockerfiles _없는_ 수는 상대적으로 작아 보였습니다 Dockerfile.go 가 아마도 가장 흔한 것 같았습니다. 이를 제외할 수 있다면 언어 분류 정확도가 상당히 향상될 것입니다.

또 다른 문제는 dockerfile.go 가 Dockerfile 로 잘못 식별된 후 Change Language Mode 명령을 사용하여 언어를 전환하면 구문 강조 표시가 완전히 엉망이 된다는 것입니다.

업스트림 https://github.com/microsoft/vscode/issues/105590 이 거부되면 이를 닫겠습니다. Dockerfile.* 를 Dockerfile로 인식하여 현재 상태를 유지하는 것이 최선의 전략이라고 생각합니다. 계속해서 피드백을 받으면 재고할 수 있습니다.

@segevfiner Visual Studio Code 자체에 문제가 있는 것 같습니다. 이에 대해 열려 있는 문제가 있습니까?

@rcjsuen 찾을 수 없지만 기존 키워드를 찾는 데 올바른 키워드가 무엇인지 아는 사람