Temurin-build: Clarté sur l'endroit où les paramètres de configuration doivent être définis

Créé le 8 oct. 2020 · 6Commentaires · Source: adoptium/temurin-build

Issu de la discussion sur https://github.com/AdoptOpenJDK/openjdk-build/pull/2125#pullrequestreview -504661752

L'emplacement des modifications des paramètres de configuration est quelque chose sur lequel nous devons fournir des conseils. Je suis tombé dessus en rassemblant cette section de la FAQ , car les choses se trouvent actuellement dans l'un des trois endroits. Lequel utiliser dépend de qui nous voulons être touchés et à mon avis, nous avons évité de préciser où des changements devraient être apportés, ce qui a déjà semé la confusion dans le passé. Résumé rapide:

| Localisation | Impact |
| --- | --- |
| fichiers groovy (selon ce PR) | Uniquement lors de l'exécution de nos pipelines Jenkins |
| scripts de configuration spécifiques à la plate-forme | Ceux qui utilisent build-farm / make-adopt-build-farm.sh (inc. Nos pipelines) - devraient être spécifiques à nos machines |
| build.sh | Toute personne (y compris les utilisateurs finaux) qui exécutent makejdk-any-platform.sh |

Cela dépend donc de ce que nous voulons que la dernière ligne soit. Si c'est pour permettre aux utilisateurs de répliquer les builds adopt avec les mêmes options de configuration que nous dans la mesure du possible, alors je pense que cela devrait être dans build.sh mais si nous voulons que ce soit facultatif pour les utilisateurs qui le construisent eux-mêmes, alors les pipelines jenkins ne sont pas un mauvais choix. Mais nous devrions vraiment indiquer clairement aux nouvelles personnes dans le projet où des modifications doivent être apportées, par exemple via une mise à jour de la FAQ.

Nous devrions discuter du moment où utiliser chaque type, en citant des exemples où des éléments doivent être ajoutés à chacun des trois endroits ci-dessus.

Je voudrais suggerer:

Les scripts de plate-forme lorsqu'ils affectent les variables d'environnement pour les bulids, et incluent des paramètres de configuration pour remplacer l'utilisation de la mémoire pour nos machines de construction spécifiques. Nous avons actuellement des éléments tels que l'activation de CUDA et d'OpenSSL pour OpenJ9 - ils pourraient être déplacés dans build.sh si nous voulons y avoir des spécificités de VM (le mettre dans le groovy entraînerait beaucoup plus d'édition s'ils changent).
Les scripts groovy contiennent actuellement des éléments tels que dtrace et d'autres options openJ9 telles que JITserver (je n'ai jamais été fan de les mettre ici pour être honnête) bien que l'argument en faveur de cela soit que c'est un moyen propre d'ajouter des éléments spécifiques à une version Java ou une VM, mais les définitions sont quelque peu opaques si vous n'utilisez pas jenkins. Peut-être devrions-nous les garder pour des choses spécifiques à jenkins, comme les suites de tests à exécuter par défaut et peut-être les options pour différencier les constructions de tas normales et volumineuses et supprimer tout le reste?
build.sh définit des éléments tels que les informations de notre fournisseur, etc. qui indiquent qui l'a construit, où eto signale les bogues ainsi que des indicateurs séparés pour les versions GA. Nous avons des choses comme freetype alsa , et des chemins de développement X11 définis ici (peut-être qu'ils devraient être dans les scripts de la plate-forme). Je suggérerais que, pour un impact maximal, si nous voulons adopteropenjdk systématiquement construit d'une manière spécifique, les développeurs peuvent répliquer la plupart de nos options de configuration par défaut qui ont un impact sur la façon dont OpenJDK est construit devraient être ici (ou l'un des scripts appelés form it)

Comprendre où apporter des modifications aux scripts de construction dans leur ensemble fait également partie de https://github.com/AdoptOpenJDK/openjdk-build/issues/957 mais je crée ceci pour limiter un peu la portée afin de clarifier ce problème important.

documentation enhancement help wanted

Source

sxa

👍1

Tous les 6 commentaires

Nous avons également eu un problème ouvert pour diviser nos fichiers entre les dépôts, je pense que cela aiderait ...

karianna le 8 oct. 2020

👍1

Je n'étais pas trop convaincu par la fragmentation comme ça, mais quoi qu'il en soit, nous aurions besoin de décider de ce qui devrait être où, et documenter ce serait une première étape triviale (Eh bien, décider serait une bonne première étape, alors nous pouvons documenter)

sxa le 9 oct. 2020

Les options de configuration définies dans les scripts build.sh et groovy doivent être fusionnées dans les scripts de la plate-forme, et je pense que les scripts doivent ensuite être déplacés sous makejdk-any-platform.sh. Passer un seul indicateur (par exemple --use-default-config-args) pourrait les déclencher, ou omettre cet indicateur les désactiverait (donc les scripts n'utilisent que les arguments de configuration de l'utilisateur).

Ces choses sont une bonne idée car:

Il n'y aurait qu'un seul emplacement où les arguments de configuration sont définis, ce qui facilite leur recherche et leur modification.
Déplacer les scripts de la plate-forme sous makejdk-any-platform.sh signifie qu'une construction de docker utilisant nos images de docker n'a qu'à cloner le référentiel unique (une fois que nous avons terminé de diviser le dépôt de compilation).
Un utilisateur peut lancer makejdk-any-platform.sh sans avoir à définir d'arguments de configuration, et être assuré que la configuration de construction aura toutes les options dont elle a besoin, en supposant qu'il utilise l'un de nos fichiers docker pour la construction.
Nous pouvons définir des "plages" de version pour chaque argument de configuration, plutôt que de copier les mêmes fichiers de configuration pour chaque version. Cela signifie moins de fichiers, moins de duplication de code et réduit également le nombre de choses qui peuvent mal tourner lorsque nous nous préparons pour de nouvelles versions d'OpenJDK.

adamfarley le 4 déc. 2020

Quand j'ai essayé d'implémenter l'action build-jdk, j'ai commencé à partir de readme et j'ai utilisé makejdk-any-platform.sh pour construire jdk, ce qui signifie que les configurations spécifiques à la plate-forme sont invisibles.

Je me demandais si nous pouvions déplacer des fichiers sous des configurations spécifiques à la plate-forme pour être au même niveau que build.sh afin que jenkins, les actions git-hub, les utilisateurs pour créer jdk nativement, etc., quels que soient les environnements de système de construction, pourraient également utiliser il? Ces configurations spécifiques à la plate-forme sont spécifiques à la plate-forme, et non à Jenkins, je suppose.

Les scripts Groovy sont des scripts de construction spécifiques à Jenkins, qui seront divisés en référentiel séparé https://github.com/AdoptOpenJDK/openjdk-build/issues/1108?

sophia-guo le 7 déc. 2020

👍1

Les paramètres de Groovy jenkins ont été clarifiés dans le README.md du repo jenkins via https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67. Les utilisateurs doivent maintenant avoir une bonne idée de la portée des paramètres disponibles et de l'endroit où de nouveaux doivent être créés. # 2506 ajuste la FAQ de ce côté du projet.

J'ai maintenant l'intention d'ajuster la FAQ de ce repo (openjdk-build) pour clarifier que les paramètres spécifiques de jenkins doivent être effectués à l' adresse https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67 où les paramètres basés sur la machine et les paramètres globaux doivent être effectués respectivement dans les fichiers de la plateforme et dans build.sh

M-Davies le 3 mars 2021

https://github.com/AdoptOpenJDK/openjdk-build/pull/2518 a été fusionné, complétant les modifications de la documentation. Cela devrait gérer toute personne souhaitant ajouter de nouveaux paramètres au projet. La dernière partie de ce numéro consistera à examiner nos paramètres et nos emplacements existants, en évaluant chacun pour sa pertinence à son emplacement actuel et, sur la base de cette évaluation, s'ils doivent être déplacés vers un autre emplacement. Ce sera cependant beaucoup de travail et il est peu probable que j'aie le temps de terminer cette tâche dans un délai raisonnable compte tenu de plusieurs tâches de priorité plus élevée que je gère en ce moment.

En tant que tel, je supprimerai mon affectation et je laisserai à quelqu'un d'autre le soin de réévaluer nos paramètres existants.

M-Davies le 10 mars 2021

👍1

Cette page vous a été utile?

0 / 5 - 0 notes