Temurin-build: 構成パラメーターを定義する場所の明確化

また、ファイルをリポジトリ間で分割する問題が発生しました。これが役立つと思います...

私はそのように断片化することにあまり確信がありませんでしたが、どこに何を置くべきかを決定する必要があり、それを文書化することは簡単な最初のステップになります（まあ、決定することは良い最初のステップであり、それから文書化できます）

build.shスクリプトとgroovyスクリプトの両方で設定されたconfigureオプションは、プラットフォームスクリプトにマージする必要があります。その後、スクリプトをmakejdk-any-platform.shの下に移動する必要があると思います。 単一のフラグ（例：-use-default-config-args）を渡すとトリガーされるか、そのフラグを省略すると無効になります（したがって、スクリプトはユーザーの構成引数のみを使用します）。

これらのことは良い考えです：

• 構成引数が設定される場所は1つだけなので、それらを見つけて変更するのが簡単になります。
• makejdk-any-platform.shの下にプラットフォームスクリプトを移動するということは、Dockerイメージを使用するDockerビルドは、1つのリポジトリのクローンを作成するだけでよいことを意味します（ビルドリポジトリの分割が完了した後）。
• ユーザーはconfigure引数を設定せずにmakejdk-any-platform.shを起動でき、ビルドにドッカーファイルの1つを使用していると仮定すると、ビルド構成に必要なすべてのオプションがあることが保証されます。
• リリースごとに同じ構成ファイルをコピーするのではなく、構成引数ごとにバージョンの「範囲」を設定できます。 これは、ファイルが少なくなり、コードの重複が少なくなり、新しいOpenJDKバージョンの準備をしているときに問題が発生する可能性のあるものの数も減ることを意味します。

build-jdkアクションを実装しようとしたとき、 readmeから開始し、makejdk-any-platform.shを使用してjdkをビルドしました。これは、プラットフォーム固有の構成が表示されないことを意味し

プラットフォーム固有の構成でファイルをbuild.shと同じレベルに移動して、jenkins、git-hubアクション、jdkをネイティブにビルドするユーザーなどを、ビルドシステム環境に関係なく使用できるかどうか疑問に思いました。それ？ これらのプラットフォーム固有の構成はプラットフォーム固有であり、ジェンキンス固有ではないと思います。

Groovyスクリプトはjenkins固有のビルドスクリプトであり、個別のリポジトリに分割されますhttps://github.com/AdoptOpenJDK/openjdk-build/issues/1108？

Groovy jenkinsパラメーターは、 https： //github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67を介してjenkinsリポジトリのREADME.mdで明確にされてい

私は今、この（openjdk-build）リポジトリのFAQを調整して、jenkins固有のパラメーターをhttps://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67で実行する必要があることを明確にするつもりです。およびグローバルパラメータは、それぞれプラットフォームファイルとbuild.shで実行する必要があります

https://github.com/AdoptOpenJDK/openjdk-build/pull/2518がマージされ、ドキュメントの変更が完了しました。 これは、プロジェクトに新しいパラメータを追加したい人を処理する必要があります。 この問題の最後の部分は、既存のパラメータと場所を調べ、現在の場所での適切性についてそれぞれを評価し、この評価に基づいて、別の場所に移動する必要があるかどうかを評価することです。 ただし、これは大変な作業であり、現在処理している優先度の高い複数のタスクを考慮すると、妥当な期間内にこのタスクを完了する時間はないでしょう。

そのため、割り当てを削除し、他の誰かに任せて既存のパラメータを再評価します。