2017-11-24 9 views
2

私は、私のリポジトリからbuild.shを実行するJenkinsジョブをセットアップしました。ジョブは次のエラーで開始および終了します。Gitの行末

d:\jenkins\workspace\test-win7>c:\cygwin64\bin\bash.exe -xe build.sh + $'\r' build.sh: line 2: $'\r': command not found

これは、行末の問題が原因で発生することがわかりました。私はbuild.shをCRLFエンディングでメモ帳++に書いています。そして私は以下のオプションで.gitattributesファイルを使用しましたが、それらのどれも動作しません。私もLFのエンディングでファイルを保存してコミットしましたが、このエラーは消えません。誰かが、この行末システムの仕組みを私に説明するのに十分親切かもしれませんか? .gitattributesファイルにどのような設定をして、私のビルドがJenkinsで動作するようにしてください。そして、私のレポから引っ張ってくる友達は影響を受けません。

  • *.sh text eol=lf
  • マイ・ジェンキンス

  • * text=auto
  • *.sh text eol=crlf
    • は、ノードがWindowsノードで構築します。私はWindowsのローカルマシンでEclipseで私の開発を行います。

    答えて

    2

    eolを.shファイル用のUNIXスタイルに直接置きます。

    ビルド環境がWindows上にある場合でも、cygwin環境を正しく使用していますか?とにかく、ウィンドウコマンドインタープリタcmd.exeは、最初にシェルスクリプトを理解することができないので、Windowsキャリッジリターンを心配する必要はありません。

    Optionally, you can configure the way Git manages line endings on a per-repository basis by configuring a special .gitattributes file. This file is committed into the repository and overrides an individual's core.autocrlf setting, ensuring consistent behavior for all users, regardless of their Git settings. The advantage of a .gitattributes file is that your line configurations are associated with your repository. You don't need to worry about whether or not collaborators have the same line ending settings that you do.

    The .gitattributes file must be created in the root of the repository and committed like any other file.

    A .gitattributes file looks like a table with two columns:

    On the left is the file name for Git to match. On the right is the line ending configuration that Git should use for those files.

    Here's an example .gitattributes file. You can use it as a template for your repositories:

    # Set the default behavior, in case people don't have core.autocrlf set. 
    * text=auto 
    
    # Explicitly declare text files you want to always be normalized and converted 
    # to native line endings on checkout. 
    *.c text 
    *.h text 
    
    # Declare files that will always have CRLF line endings on checkout. 
    *.sln text eol=crlf 
    
    # Denote all files that are truly binary and should not be modified. 
    *.png binary 
    *.jpg binary 
    

    You'll notice that files are matched --*.c, *.sln, *.png-- , separated by a space, then given a setting --text, text eol=crlf, binary . We'll go over some possible settings below.

    text=auto Git will handle the files in whatever way it thinks is best. This is a good default option. text eol=crlf Git will always convert line endings to CRLF on checkout. You should use this for files that must keep CRLF endings, even on OSX or Linux. text eol=lf Git will always convert line endings to LF on checkout. You should use this for files that must keep LF endings, even on Windows. binary Git will understand that the files specified are not text, and it should not try to change them. The binary setting is also an alias for -text -diff .

    出典:https://help.github.com/articles/dealing-with-line-endings/ 追加測定値:私が正しく理解しています場合How to change line-ending settings

    +0

    だから、私は '中= lf'文のように' * .SHテキストEOLを持っている必要があります。 gitattributes'ファイル?これは、JenkinsがビルドノードでGitリポジトリをチェックアウトすると、ビルドノードのcygwinインスタンスで 'lf'が終了して正しく実行されるすべてのスクリプトをチェックアウトすることを意味しますか? –

    関連する問題