Temurin-build: Claridad sobre dónde se deben definir los parámetros de configuración
Derivado de la discusión en https://github.com/AdoptOpenJDK/openjdk-build/pull/2125#pullrequestreview -504661752
La ubicación de los cambios en los parámetros de configuración es algo sobre lo que debemos proporcionar orientación. Me lo encontré al juntar esta sección de las preguntas frecuentes, ya que las cosas están actualmente en uno de tres lugares. Cuál usar depende de quiénes queremos que se vean afectados y, en mi opinión, hemos evitado tener claro dónde se deben realizar los cambios, lo que ya ha generado confusión en el pasado. Sumario rápido:
| Ubicacion | Impacto |
| --- | --- |
| archivos maravillosos (según este PR) | Sólo cuando se ejecuta a través de nuestras tuberías jenkins |
| scripts de configuraciones específicas de plataforma | Aquellos que usan build-farm / make-adopt-build-farm.sh (incluyendo nuestras canalizaciones) - deben ser cosas específicas para nuestras máquinas |
| build.sh | Cualquiera (incluidos los usuarios finales) que esté ejecutando makejdk-any-platform.sh |
Así que depende de cuál queramos que sea la última línea de esas. Si es para permitir a los usuarios replicar las compilaciones de adopción con las mismas opciones de configuración que nosotros en la medida de lo posible, entonces creo que debería estar en build.sh, pero si queremos que sea opcional para los usuarios que lo construyen ellos mismos, entonces las canalizaciones de jenkins no es una mala elección. Pero realmente deberíamos dejar claro a las personas nuevas en el proyecto dónde se deben realizar los cambios, por ejemplo, mediante una actualización de las preguntas frecuentes.
Deberíamos discutir cuándo usar cada tipo, citando ejemplos de cuándo se deben agregar cosas en cada uno de los tres lugares anteriores.
Yo sugeriría:
- Los scripts de la plataforma cuando afectan las variables de entorno para los bulids, e incluyen parámetros de configuración para anular el uso de memoria para nuestras máquinas de compilación específicas. Actualmente tenemos cosas como la habilitación de CUDA y OpenSSL para OpenJ9 allí; podrían trasladarse a build.sh si queremos tener detalles de VM allí (ponerlo en el groovy resultaría en muchas más ediciones si cambian).
- Los scripts geniales actualmente tienen cosas como dtrace y otras opciones de openJ9 como JITserver (nunca fui un fanático de ponerlas aquí para ser honesto) aunque el argumento a favor es que es una forma limpia de agregar cosas específicas a una versión de Java o VM, sin embargo, las definiciones son algo opacas si no está usando jenkins. ¿Quizás deberíamos mantenerlos para cosas específicas de jenkins, como qué conjuntos de pruebas se ejecutarán de forma predeterminada y quizás las opciones para diferenciar compilaciones de montón normales y grandes y eliminar todo lo demás?
- build.sh establece cosas como la información de nuestro proveedor, etc., que indica quién lo construyó, dónde informar errores, así como banderas separadas para compilaciones GA. Tenemos cosas como
freetypealsa, y rutas de desarrollo X11 definidas allí (tal vez deberían estar en los scripts de la plataforma). Sugeriría que para un impacto máximo, si queremos que adoptopenjdk se construya de manera consistente de una manera específica, los desarrolladores pueden replicar la mayoría de nuestras opciones de configuración predeterminadas que afectan la forma en que se construye OpenJDK debería estar aquí (o uno de los scripts llamados form it)
Comprender dónde realizar cambios en los scripts de compilación en general también es parte de https://github.com/AdoptOpenJDK/openjdk-build/issues/957, pero estoy creando esto para limitar un poco el alcance y aclarar este importante problema.
sxa
Todos 6 comentarios
También tuvimos un problema abierto para dividir nuestros archivos entre repositorios, creo que eso ayudaría ...
karianna
en 8 oct. 2020
No estaba muy convencido de fragmentar de esa manera, pero independientemente de lo que necesitemos decidir qué debería estar y dónde, y documentarlo sería un primer paso trivial (bueno, decidir sería un buen primer paso, luego podemos documentar)
sxa
en 9 oct. 2020
Las opciones de configuración establecidas tanto en build.sh como en los scripts groovy deben fusionarse en los scripts de la plataforma, y creo que los scripts deberían moverse a makejdk-any-platform.sh. Pasar una sola bandera (por ejemplo, --use-default-config-args) podría activarlos, u omitir esa bandera los deshabilitaría (por lo que los scripts solo usan los argumentos de configuración del usuario).
Estas cosas son una buena idea porque:
- Solo habría una ubicación donde se establecen los argumentos de configuración, lo que facilita su búsqueda y cambio.
- Mover los scripts de la plataforma en makejdk-any-platform.sh significa que una compilación de la ventana acoplable que usa nuestras imágenes de la ventana acoplable solo tiene que clonar un repositorio (después de que hayamos terminado de dividir el repositorio de compilación).
- Un usuario puede iniciar makejdk-any-platform.sh sin tener que establecer ningún argumento de configuración, y estar seguro de que la configuración de compilación tendrá todas las opciones que necesita, asumiendo que está usando uno de nuestros archivos de la ventana acoplable para compilar.
- Podemos establecer "rangos" de versión para cada argumento de configuración, en lugar de copiar los mismos archivos de configuración para cada versión. Esto significa menos archivos, menos duplicación de código y también reduce la cantidad de cosas que pueden salir mal cuando nos estamos preparando para nuevas versiones de OpenJDK.
adamfarley
en 4 dic. 2020
Cuando intenté implementar la acción build-jdk, comencé desde el archivo Léame y usé makejdk-any-platform.sh para compilar jdk, lo que significa que las configuraciones específicas de la plataforma son invisibles.
Me preguntaba si podríamos mover archivos bajo configuraciones específicas de plataforma para que tengan el mismo nivel de build.sh, de modo que jenkins, acciones de git-hub, usuarios para construir jdk de forma nativa, etc., sin importar qué entornos de sistema de compilación sean, también podrían usar ¿eso? Esas configuraciones específicas de la plataforma son específicas de la plataforma, no específicas de Jenkins, supongo.
Los scripts maravillosos son scripts de compilación específicos de jenkins, que se dividirán en repositorios separados https://github.com/AdoptOpenJDK/openjdk-build/issues/1108?
sophia-guo
en 7 dic. 2020
Los parámetros de Groovy jenkins se han aclarado en el README.md del repositorio de jenkins a través de https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67. Los usuarios ahora deben tener un buen sentido del alcance con respecto a qué parámetros están disponibles y dónde se deben crear nuevos. # 2506 ajusta las preguntas frecuentes en este lado del proyecto.
Ahora tengo la intención de ajustar las preguntas frecuentes de este repositorio (openjdk-build) para aclarar que los parámetros específicos de jenkins deben realizarse en https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67 donde los parámetros basados en máquinas y los parámetros globales deben realizarse en los archivos de la plataforma y build.sh respectivamente
M-Davies
en 3 mar. 2021
https://github.com/AdoptOpenJDK/openjdk-build/pull/2518 se ha fusionado, completando los cambios de documentación. Esto debería manejar a cualquiera que quiera agregar nuevos parámetros al proyecto. La parte final de este problema será examinar nuestros parámetros y ubicaciones existentes, evaluar cada uno de ellos para determinar su idoneidad en su ubicación actual y, en función de esta evaluación, si es necesario trasladarlos a otra ubicación. Sin embargo, esto será mucho trabajo y es poco probable que tenga tiempo para completar esta tarea en un período de tiempo razonable considerando las múltiples tareas de mayor prioridad que estoy manejando en este momento.
Como tal, eliminaré mi asignación y dejaré que otra persona reevalúe nuestros parámetros existentes.
M-Davies
en 10 mar. 2021
Temas relacionados
andrew-m-leonard
·
26Comentarios
chrisvest
·
36Comentarios
tkie
·
120Comentarios
gchauvet
·
51Comentarios
sxa
·
21Comentarios