血と涙の歴史
最近、Jenkinsを使用してGitプロジェクトをプルしてコードをコンパイルするときに、非常に奇妙な問題が発生しました。JenkinsのGitPluginダウンロードコードのバージョンが間違っています（commitIdが間違っています）。オンラインデプロイメントとオフラインデプロイメントのコンパイル済み製品は同じバージョンであるため、最終的に本番環境にリリースされたコードバージョンは正しくありません。この問題は、オンライン検証フェーズで最終的に発見されました。ジョブ構築プロセス全体を振り返ると、コンソールはエラーを報告せず、オンラインパッケージは正常にコンパイルされました。
初期配置
最初は、ローカルGitプロジェクトの残りの問題であると思われたので、jenkins ビルドがトリガーされたときに最新のコードが確実にプルされるように、jenkinsに対応するジョブが実行されているマシンノードのWORKSPACEディレクトリを削除しようとしました。
削除方法：
1.ジョブが実行されているマシンにログインします（コンソールでジョブが実行されているノードを確認してください。最初の行に印刷があります）。
2. $ WORKSPACEを確認します（ジョブコンソールで確認します。見つからない場合は、echo $ WORKSPACEの行をシェルエグゼキューターに追加して、ジョブを再実行します）。
3.対応するWORKSPACE情報を削除します。注意して操作してください。最初にWORKSPACEの値が正しいかどうか（echo $ WORKSPACE）を確認してください。間違えないようにして、ルートディレクトリを削除してください。！！。
[-d "$ WORKSPACE"] && rm -rf $ {WORKSPACE}
4.削除後にジョブを再トリガーします
これを行った後でも、最終的にパッケージ化されたコンパイル済み製品のバージョンは正しくありません。
ローカルコードキャッシングの問題ではないので、GItがコードをプルしたときにバージョンが間違っている可能性はありますか？
2番目のトラブルシューティング
Jenkinsでジョブ構成の詳細を開きます。BranchSpecifierに「* / qa」のみを入力しました。私の期待は、git固有のプロジェクト（リポジトリURL）のqaブランチと一致することです。
次に、問題があった前のビルドのレコードを確認し（現在のビルドのジョブの詳細ページを開く）、[Gitビルドデータ]（左側）をクリックします。
ここには2つのリモートブランチが表示されています。GitPluginで設定したqaブランチは1つだけです。ダウンロードされるqaというブランチは1つだけです。どうして2つのブランチがあるのですか？
私は、Gitプラグインの構成でBranchNameのルールマッチングの問題である可能性があると疑い始めました。これにより、2つのブランチがここで一致しました（1つはqaと呼ばれ、もう1つはorigin / qaと呼ばれます）。
Jenkinsで対応するジョブの構成を再度開きます。「* / qa」がBranchSpecifierに入力されていることがわかります。*はワイルドカードです。上図に示すように、このプロジェクトには正確に2つのブランチがあります（origin / qaそしてqa）、* / qaと完全に一致しますか？
このように考えると、理にかなっているので、Branches Specifier列の右側にある疑問符をクリックしてヘルプを表示すると、ヘルプ情報が表示されました。
詳細な分析
//次の文は、分岐指定子を入力しない場合（空白のままにするか、書き込む場合）、どの分岐も一致することを示します。つまり、プロジェクトで使用できない分岐です。これは一般に推奨されません。
リポジトリ内の特定のブランチを追跡する場合は、ブランチを指定します。空白のままにすると、すべてのブランチの変更が調査され、ビルドされます。
//次の文の意味：最も安全な方法は、refs / heads / <branchName>の構文を使用することです
最も安全な方法は、refs / heads / <branchName>構文を使用することです。このようにして、予想されるブランチは明確になります。
//ブランチに「/」が含まれている場合（たとえば、origin / qa）、上記の構文を使用するのが最適です：refs / heads / <branchName>
ブランチ名に/が含まれている場合は、必ず上記の完全なリファレンスを使用してください。フルパスが表示されていない場合、プラグインは最後のスラッシュの右側の文字列の一部のみを使用します。foo / barは実際にはbarと一致します。
ワイルドカードブランチ指定子をスラッシュ付きで使用する場合（例：release /）、ブランチ名でオリジンリポジトリを指定して、変更が確実に反映されるようにする必要があります。したがって、たとえばorigin / release /
可能なオプション：
<branchName> // branchNameは単なるワイルドカードです。たとえば、realeseはリリースブランチと一致することもあれば、origin / releaseと一致することもあります。通常、これを記述しないでください（そうしないと、私のような同じピットを踏むことになります）
// <branchName>の指定はあいまいであるため、refs / heads / <branchName>を使用して特定のリモートブランチを明確に指定することをお勧めします。
指定されたブランチを追跡/チェックアウトします。あいまいな場合、最初の結果が取得されますが、これは必ずしも期待される結果ではありません。refs / heads / <branchName>を使用することをお勧めします。
たとえば、master、feature1、...
refs / heads / <branchName>
指定されたブランチを追跡/チェックアウトします//リモートブランチをチェックアウトします
たとえば、refs / heads / master、refs / heads / feature1 / master、...
<remoteRepoName> / <branchName>
指定されたブランチを追跡/チェックアウトします。あいまいな場合、最初の結果が取得されますが、これは必ずしも期待される結果ではありません。
refs / heads / <branchName>を使用することをお勧めします。//この特定のリモートブランチを指定する方法はあいまいな場合があります。refs/ heads / <branchName>を使用することをお勧めします
例えば起源/マスター
リモート/ <remoteRepoName> / <branchName>
指定されたブランチを追跡/チェックアウトします//この指定方法もより正確です。
例：リモート/オリジン/マスター
refs / remotes / <remoteRepoName> / <branchName>
指定されたブランチを追跡/チェックアウトします。
例：refs / remotes / origin / master //チェックアウトで指定されたタグ。実際、ここでのtagNameはタグと見なされないため、書き込むことはお勧めしません。
<タグ名>
タグがタグとして認識されないため、これは機能しません。
代わりにrefs / tags / <tagName>を使用してください.. //指定したタグをチェックアウトしてください。これは正しい構文です。
例：git-2.3.0
refs / tags / <tagName>
指定されたタグを追跡/チェックアウトします。
例：refs / tags / git-2.3.0
<commitId>
指定されたコミットをチェックアウトします。// checkout指定的commitid
例5062ac843f2b947733e6a3b105977056821bd352、5062ac84、...
$ {ENV_VARIABLE}
環境変数を使用することもできます。この場合、変数が評価され、結果が上記のように使用されます。
例：$ {TREEISH}、refs / tags / $ {TAGNAME}、...
<ワイルドカード>
構文はREPOSITORYNAME / BRANCHの形式です。さらに、BRANCHは* / BRANCHの省略形として認識され、「*」はワイルドカードとして認識され、「**」は区切り文字「/」を含むワイルドカードとして認識されます。したがって、origin / branches *はorigin / branches-fooと一致しますが、origin / branches / fooとは一致しませんが、origin / branches **はorigin / branches-fooとorigin / branches / fooの両方と一致します。
：<正規表現>
構文は、：regexpの形式です。ビルドするブランチの正規表現構文は、名前が正規表現に一致するブランチのみをビルドします。
例：
：^（？！（origin / prefix））*
一致：originまたはorigin / masterまたはorigin / feature
一致しない：origin / prefixまたはorigin / prefix_123またはorigin / prefix-abc
：origin / release- \ d {8}
一致：origin / release-20150101
一致しない：origin / release-2015010またはorigin / release-201501011またはorigin / release-20150101-something
：^（?! origin / master $ | origin / develop $）。*
一致：origin / branch1またはorigin / branch-2またはorigin / master123またはorigin / develop-123
一致しない：origin / masterまたはorigin / develop
したがって、プルする特定のブランチを指定する場合、明確な4つの明確な書き込み方法は次のとおりです。
refs / heads / <branchName>
refs / remotes / <remoteRepoName> / <branchName>
refs / tags / <tagName>
<commitId>
ここでの基本的な問題は真実です。gitlabに行ってこのプロジェクトのブランチリストを調べたところ、実際にorigin / qaというブランチがあることがわかりました。他の同僚と確認した後、誰かが握手してこのorigin / qaを作成しました。ブランチ。
オリジナルの* / qaに置き換えられたrefs / Heads / qaを配置したので、特定のブランチに正確に一致しました。ジョブビルドをもう一度トリガーしてみてください。今回は、ダウンロードしたGitコードのバージョンも正しいです。
この記事は、ピットに足を踏み入れた元々の歴史ですので、参考になりましたら、よろしくお願いします！
ブロガー：お金を稼ぐためのテスト
モットー：テストキャリアを介して元の蓄積を完了し、投資を通じて経済的自由を目指します
csdn：https ://blog.csdn.net/ccgshigao
ブログパーク：https : //www.cnblogs.com/qa-freeroad/
51cto：https ://blog.51cto.com/14900374