Temurin-build: Clareza sobre onde os parâmetros de configuração devem ser definidos

Criado em 8 out. 2020 · 6Comentários · Fonte: adoptium/temurin-build

Retirado da discussão em https://github.com/AdoptOpenJDK/openjdk-build/pull/2125#pullrequestreview -504661752

O local para alterações nos parâmetros de configuração é algo sobre o qual precisamos fornecer orientação. Eu me deparei com isso ao montar esta seção do FAQ , já que as coisas estão atualmente em um dos três lugares. O que usar depende de quem queremos ser afetados e, pelo meu conhecimento, evitamos deixar claro onde as alterações devem ser feitas, o que já causou confusão no passado. Resumo rápido:

| Localização | Impacto |
| --- | --- |
| arquivos bacanas (de acordo com este PR) | Somente quando executado por meio de nossos pipelines Jenkins |
| scripts de configurações específicas da plataforma | Aqueles que usam build-farm / make-adopt-build-farm.sh (incluindo nossos pipelines) - devem ser específicos para nossas máquinas |
| build.sh | Qualquer pessoa (incluindo usuários finais) que esteja executando makejdk-any-platform.sh |

Portanto, depende de como queremos que seja a última linha. Se for para permitir que os usuários replicem as compilações adotadas com as mesmas opções de configuração que nós, na medida do possível, então acho que deveria estar no build.sh, mas se quisermos que seja opcional para os usuários que criam eles próprios, então os pipelines jenkins não são uma escolha ruim. Mas devemos realmente deixar claro para novas pessoas no projeto onde as alterações devem ser feitas, por exemplo, por meio de uma atualização do FAQ.

Devemos discutir quando usar cada tipo, citando exemplos de quando as coisas devem ser adicionadas em cada um dos três lugares acima.

Eu sugeriria:

Os scripts de plataforma quando afetam variáveis de ambiente para os bulids, incluindo parâmetros de configuração para substituir o uso de memória para nossas máquinas de construção específicas. Atualmente, temos coisas como a ativação de CUDA e OpenSSL para OpenJ9 lá - eles podem ser movidos para build.sh se quisermos ter detalhes da VM lá (colocá-los no groovy resultaria em muito mais edições se eles mudassem).
Os scripts bacanas atualmente têm coisas como dtrace e outras opções openJ9 como JITserver (eu nunca fui fã de colocá-los aqui para ser honesto), embora o argumento a favor deles seja que é uma maneira limpa de adicionar coisas específicas para uma versão java ou VM, no entanto, as definições são um tanto opacas se você não estiver usando jenkins. Talvez devêssemos mantê-los para coisas específicas de jenkins, como quais suítes de teste executar por padrão e talvez as opções para diferenciar compilações de heap normais e grandes e remover todo o resto?
build.sh define coisas como nossas informações de fornecedor etc. que indicam quem o construiu, para relatar bugs, bem como sinalizadores separados para compilações GA. Temos coisas como freetype alsa e caminhos de desenvolvimento X11 definidos lá (talvez eles devam estar nos scripts de plataforma). Eu sugeriria que, para um impacto máximo, se quisermos adotar um sistema de construção consistente de uma maneira específica que os desenvolvedores possam replicar a maioria de nossas opções de configuração padrão que afetam como o OpenJDK é construído, deve estar aqui (ou um dos scripts chamados de forma)

Compreender onde fazer alterações nos scripts de construção em geral também faz parte de https://github.com/AdoptOpenJDK/openjdk-build/issues/957, mas estou criando isso para limitar um pouco o escopo e esclarecer esse importante problema

documentation enhancement help wanted

Fonte

sxa

👍1

Todos 6 comentários

Também tivemos um problema aberto para dividir nossos arquivos entre repositórios, acho que ajudaria ...

karianna em 8 out. 2020

👍1

Eu não estava muito convencido de fragmentar assim, mas, independentemente disso, precisaríamos decidir o que deveria estar onde, e documentá-lo seria um primeiro passo trivial (bem, decidir seria um bom primeiro passo, então podemos documentar)

sxa em 9 out. 2020

As opções de configuração definidas nos scripts build.sh e groovy devem ser mescladas com os scripts da plataforma e acho que os scripts devem ser movidos para makejdk-any-platform.sh. Passar um único sinalizador (por exemplo --use-default-config-args) pode acioná-los, ou omitir esse sinalizador pode desabilitá-los (então os scripts usam apenas os argumentos de configuração do usuário).

Essas coisas são uma boa ideia porque:

Haveria apenas um local onde os argumentos de configuração fossem definidos, tornando mais fácil localizá-los e alterá-los.
Mover os scripts de plataforma em makejdk-any-platform.sh significa que uma compilação docker usando nossas imagens docker só precisa clonar um repo (depois de terminarmos de dividir o repo de compilação).
Um usuário pode iniciar makejdk-any-platform.sh sem ter que definir nenhum argumento de configuração e ter certeza de que a configuração de compilação terá todas as opções de que precisa, supondo que ele esteja usando um de nossos arquivos docker para compilar.
Podemos definir "intervalos" de versão para cada argumento de configuração, em vez de copiar os mesmos arquivos de configuração para cada versão. Isso significa menos arquivos, menos duplicação de código e também reduz o número de coisas que podem dar errado quando estamos nos preparando para novas versões do OpenJDK.

adamfarley em 4 dez. 2020

Quando tentei implementar a ação build-jdk, comecei a partir do readme e usei makejdk-any-platform.sh para construir o jdk, o que significa que as configurações específicas da plataforma são invisíveis.

Gostaria de saber se poderíamos mover arquivos em configurações específicas de plataforma para o mesmo nível de build.sh para que jenkins, ações git-hub, usuários para construir jdk nativamente, etc., não importa quais ambientes de sistema de construção sejam, também poderiam usar isto? Essas configurações específicas da plataforma são específicas da plataforma, não específicas do Jenkins, suponho.

Os scripts Groovy são scripts de construção específicos do jenkins, que serão divididos para separar o repo https://github.com/AdoptOpenJDK/openjdk-build/issues/1108?

sophia-guo em 7 dez. 2020

👍1

Os parâmetros do Groovy jenkins foram esclarecidos no README.md do repositório jenkins via https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67. Os usuários agora devem ter um bom senso de escopo sobre quais parâmetros estão disponíveis e onde novos devem ser criados. # 2506 ajusta o FAQ neste lado do projeto.

Agora pretendo ajustar o FAQ deste repositório (openjdk-build) para esclarecer que os parâmetros específicos do jenkins devem ser feitos em https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67 onde os parâmetros baseados na máquina e parâmetros globais devem ser feitos nos arquivos da plataforma e build.sh respectivamente

M-Davies em 3 mar. 2021

https://github.com/AdoptOpenJDK/openjdk-build/pull/2518 foi mesclado, completando as alterações do documento. Isso deve lidar com qualquer pessoa que deseja adicionar novos parâmetros ao projeto. A parte final desta edição será examinar nossos parâmetros e localizações existentes, avaliando cada um quanto à sua apropriabilidade em sua localização atual e, com base nessa avaliação, se eles precisam ser movidos para outro local. No entanto, isso dará muito trabalho e é improvável que eu tenha tempo para concluir esta tarefa em um período de tempo razoável, considerando as várias tarefas de alta prioridade que estou realizando no momento.

Como tal, vou remover minha atribuição e transferir para outra pessoa para reavaliar nossos parâmetros existentes.

M-Davies em 10 mar. 2021

👍1

Esta página foi útil?

0 / 5 - 0 avaliações