warnings ng plugin devenv
1.0.0
このDockerベースの開発環境は、Jenkinsの警告とカバレッジプラグインの新しい貢献者向けで、最初のランプアップ時間を短縮します。次の部分で構成されています。
この開発環境は、2022年1月に録音されたJenkinsオンラインミートアップで発表しました。
開発環境は、MacOS、Ubuntu Linux（MacOSで実行されている仮想マシン）、およびWindowsでテストされています。プルリクエストはいつでも大歓迎です。
次のツールの最新バージョン：
さらに、次のツールの最新バージョンが必要です。
エラーが発生した場合は、以下のトラブルシューティングのヒントに注意してください。 Windowsユーザーの場合：Git Bashを使用して、シェルスクリプトを実行します。
./bin/clone-repos-https.sh既に設定している場合は./bin/clone-repos.sh githubにsshキーを設定している場合）を使用して、プラグインモジュールをクローンして構築します。 Intellijを開く前にビルドが成功するまで待つ必要があります。そうしないと、Intellijが生成されたすべてのクラスを見つけるわけではありません。 Mavenユーザーは、Maven Centralからすべての依存関係がダウンロードされるまで数分待つ必要があります。warnings-ng-plugin-devenvを選択します./bin/jenkins.shでJenkinsを開始します。このコマンドは、Jenkins Docker画像を構築し、登録されたすべてのプラグインをダウンロードし、Jenkinsワークスペースをいくつかのジョブで初期化します。これには数分も必要です（ステップ9を参照）。すべてのダウンロードが成功したが、エラーのためにインストールが失敗した場合、それらを修正してmvn -V -U -e install –DskipTestsを実行して、インストールのみを再試行します。
「コマンドラインが長すぎる」エラーがある場合。発生し、次の手順を実行します。
@argfile (Java9+)を選択しますジェンキンスのテストタイムアウトのためにテストが失敗した場合、次の手順を実行します。
-Djenkins.test.timeout=1000 。これにより、タイムアウト制限が1000秒に増加します。 Simple Shell Script（ ./bin/clone-repos.sh clone-repos.sh）を使用して、1つのステップでモジュールをクローンして構築できます。スクリプトは、GIT SSHプロトコルを使用して次のモジュールをチェックアウトします。これには、GitHubに公開キーを登録する必要があります。 Githubにキーがない場合は、HTTPSプロトコルを使用するスクリプト./bin/clone-repos-https.shを使用できます。
プラグインの1つにプルリクエストを提供する場合は、リポジトリのフォークを作成し、このフォークですべての変更を行う必要があります。コーディングスタイルプロジェクトでGitHubコラボレーションドキュメントを作成しました。
Intellij（Ultimate）は、警告プラグインの主なサポートされた開発環境です。事前定義されたプロジェクトは、警告プラグインのすべてのモジュールを参照するフォルダー.ideaに保存されます。このプロジェクトには、私のコーディングスタイルのプリセットとその他の有用な構成が含まれています。
他のIDE（Eclipse、NetBeans、Visual Studio Code）も使用できるはずです。
All in [module-name] Intellij実行構成をすべて使用して、対応するモジュールのユニットと統合テストを実行します。これらの構成は、対応するモジュールパッケージのブランチカバレッジを記録するように既に構成されています（ Run with Coverageを使用します）。
変更をデバッグする前に、最初にコードの実行場所を確認する必要があります：コントローラーまたはエージェント上？不明な場合は、両方のリモートデバッガーを実行し、ブレークポイントを設定し、対応するデバッガーが停止するのを待ちます。
Docker Compose Configurationは、「デバッグ」モードでJenkinsコントローラーを自動的に開始します。つまり、リモートデバッグリクエストを聴きます。コードがコントローラーで実行されている場合は、 localhost:8000 （Dockerコンテナの同じポートにマッピング）でリモートデバッガーを添付する必要があります。提供されたJenkins Controller (Remote Debugger)デバッグ構成を使用して、Intellijのデバッガーを接続します。
Docker Composeの構成は、「デバッグ」モードでJenkinsエージェントを自動的に起動する、つまりリモートデバッグリクエストを聴いています。 localhost:8001 （Dockerコンテナの同じポートにマッピング）にリモートデバッガーを添付して、エージェントで実行されているコードをデバッグします。提供されたJenkins Agent (Remote Debugger)デバッグ構成を使用して、Intellijのデバッガーを接続します。
UIテストは、対応するランチャーUI Tests [module] (Firefox)またはUI Tests [module] (Chrome)を使用して開始できます。両方のランチャーには、対応するセレンドライバーの設置が必要であることに注意してください。これらのドライバーがローカルマシンに/opt/binにインストールされていない場合は、セットアップに合わせてランチャー構成を適応させる必要があります。
すべてのUIテストでは、テスト中の特定の被験者内で実行される必要があります（つまり、テスト中のJenkins、JUT）、詳細についてはAcceptance Test Harnessプロジェクトを参照してください。
この開発環境には、変更されたプラグインを展開できるカスタマイズされたJenkinsインストールが含まれているため、これらのプラグインを使用する事前に構成されたジョブで変更を直接確認できます。
このプロジェクトで提供されたJenkinsコントローラーを開始します（DockerとDocker-Composeをインストールする必要があります）。端子を開き、トップレベルフォルダーで./jenkins.shを実行します。このコマンドはdocker-compose upのラッパーです。適切なユーザーとグループ設定を使用して、Jenkins HomeフォルダーのDockerボリュームの許可が正しく設定されます。このコマンドは、Jenkinsコントローラー用のDockerコンテナとJavaエージェント用のDockerコンテナを作成します。これには、Docker画像が作成されるため、初めて呼び出された場合にはしばらく時間がかかります。画像が作成された後、次の2つのコンテナが開始されます。
その後、URL http：// localhost：8080/でJenkinsを開くことができます。次の資格情報を使用して、管理者としてログインします。
Jenkins Controller（Jenkins_home）のホームディレクトリは、Dockerボリュームとして取り付けられています。つまり、 ./docker/volumes/jenkins-controller docker/volumes/jenkins-controllerの通常のディレクトリとしてホストに表示されます。セッションに耐えられ、ホストで直接変更できます。詳細については、公式のドキュメントを参照してください。これにより、Jenkinsコントローラーによって作成されたファイルを検査するのに役立ちます。
JenkinsのJob DSLプラグインのパフォーマンスの問題により、新しいJenkinsインスタンスのセットアップは非常に遅いです。したがって、ジョブが作成された後、 jenkins.yamlファイルのジョブの構成部分を削除することは理にかなっています。ファイルのコンテンツを上書きすることができます./docker/volumes/jenkins-home/jenkins.yaml新しく作成したJenkinsインスタンスではjenkins-no-jobs.yamlのコンテンツを使用できます。
MacOSの下のボリュームは非常に遅いです。 Dockerコンテナのanalysis-modelの提供されたJenkinsの仕事を実行している私のMacBookでは、同じMacBookのLinux仮想マシンで実行されているDockerコンテナで同じJenkinsのジョブを実行するよりも遅くなります（不条理な音？）。
ローカル開発の変更を終了したら（つまり、単体テストはすべて緑色です）、Jenkinsで変更をテストする必要があります。これは、変更のための統合テストまたはUIテストを準備するのにも役立ちます。
analysis-modelモジュールの変更のみがある場合（および新しいAPIメソッドが追加されていません）、Maven Module analysis-model.jarを再構築およびインストールし、その後関連するJenkinsラッパープラグインanalysis-model-api-pluginする必要があります。このプラグインは、Jenkinsに展開する必要があります。
このプロセスは、 analysis-modelモジュールでスクリプト./bin/go.shを実行することで簡素化され、ローカルMavenリポジトリにモジュールanalysis-model.jarをインストールします。次に、このスクリプトは実際のプラグインを構築し、ジェンキンスに展開します。
警告-NGプラグインの変更のみがある場合は、Jenkins Plugin warnings-ng.jpiを再構築し、Jenkinsに展開する必要があります。このタスクには、次のシェルスクリプトのいずれかを使用できます。
./bin/clean.sh mvn clean installを使用してプラグインを構築し、Jenkinsインスタンスに成功に展開します。./bin/go.sh mvn clean install -DskipITs （統合テストをスキップ）を使用してプラグインを構築し、成功してJenkins Instaceに展開します。./bin/skip.sh mvn clean install -DskipTests （すべてのテストと静的分析をスキップ）を使用してプラグインを構築し、成功してJenkinsインスタンスに展開します。トト
Foresicsプラグインの1つ（APIまたはGit実装）に変更がある場合は、これらのJenkinsプラグインを再構築してJenkinsインスタンスに展開する必要があります。
このプロセスを簡素化するために、対応するプラグインフォルダーでScript ./go.shを実行すると、プラグインを構築し、成功してJenkinsに展開します。
変更を加える前に、私に連絡してください。通常、変更を後方に互換性のあるものにすることができます。
最後のセクションのビルドスクリプトは、[Intellij Launchers Build and Deploy [module-name]の1つを使用して）を開始することもできます。これらのランチャーは、対応するプラグインを構築し、ジェンキンスに展開します。
UIテストは、Intellij Launcher構成の使用またはコマンドラインスクリプトを使用して開始できます。すでに述べたように、すべてのUIテストでは、テスト中の特定の被験者内で実行する必要があります。この場合、利用可能な最新のJenkins LTSバージョンと、Docker画像から事前定義されたプラグインセットを使用します。
UIテストは、対応するランチャーUI Tests Warnings (Firefox)またはUI Warnings Tests (Chrome)を使用して開始できます。両方のランチャーには、対応するセレンドライバーの設置が必要であることに注意してください。これらのドライバーがローカルマシンに/opt/binにインストールされていない場合は、セットアップに合わせてランチャー構成を適応させる必要があります。
また、提供されたシェルスクリップtestFirefox.shまたはtestChrome.shを使用してUIテストを開始することもできます。これらのスクリプトも適応する必要がある場合があることに注意してください（前のセクションを参照）。
