Temurin-build: Ясность в том, где должны быть определены параметры конфигурации

Созданный на 8 окт. 2020 · 6Комментарии · Источник: adoptium/temurin-build

Вырвано из обсуждения в https://github.com/AdoptOpenJDK/openjdk-build/pull/2125#pullrequestreview -504661752

Нам нужно дать указания относительно места изменения параметров конфигурации. Я столкнулся с этим, когда собирал этот раздел FAQ, так как в настоящее время все находится в одном из трех мест. Что использовать, зависит от того, кого мы хотим затронуть, и, насколько мне известно, мы избегали ясности в отношении того, где следует внести изменения, что уже приводило к путанице в прошлом. Краткое резюме:

| Расположение | Воздействие |
| --- | --- |
| Groovy файлы (согласно этому PR) | Только через наши трубопроводы Дженкинса |
| скрипты конфигурации для конкретной платформы | Те, кто использует build-farm / make-adopt-build-farm.sh (включая наши конвейеры) - должны быть специфичными для наших машин |
| build.sh | Всем (включая конечных пользователей), кто запускает makejdk-any-platform.sh |

Так что это зависит от того, какой мы хотим видеть последнюю строку из них. Если он позволяет пользователям копировать принятые сборки с теми же параметрами конфигурации, что и мы, насколько это возможно, то я думаю, что он должен быть в build.sh, но если мы хотим, чтобы он был необязательным для пользователей, создающих его самостоятельно, тогда конвейеры jenkins неплохой выбор. Но мы действительно должны прояснить для новых людей в проекте, где следует вносить изменения, например, через обновление FAQ.

Мы должны обсудить, когда использовать каждый тип, приводя примеры того, когда что-то должно быть добавлено в каждом из трех вышеуказанных мест.

Я бы посоветовал:

Сценарии платформы, когда это влияет на переменные среды для Bulid, и включая параметры конфигурации, чтобы переопределить использование памяти для наших конкретных машин сборки. В настоящее время у нас есть такие вещи, как включение CUDA и OpenSSL для OpenJ9 - их можно переместить в build.sh, если мы хотим, чтобы там были специфические особенности виртуальной машины (если их поместить в groovy, это приведет к гораздо большему редактированию, если они изменятся).
В сценариях groovy в настоящее время есть такие вещи, как dtrace и другие параметры openJ9, такие как JITserver (честно говоря, я никогда не был поклонником их добавления), хотя аргумент в пользу этого заключается в том, что это чистый способ добавить вещи, специфичные для версия java или виртуальная машина, однако определения несколько непрозрачны, если вы не используете jenkins. Возможно, нам стоит оставить их для специфичных для Дженкинса вещей, например, какие наборы тестов запускать по умолчанию и, возможно, вариантов различать обычные и большие сборки кучи и вырезать все остальное?
build.sh устанавливает такие вещи, как информация о нашем поставщике и т. д., которая указывает, кто его создал, где он сообщает об ошибках, а также отдельные флаги для сборок GA. У нас есть такие вещи, как freetype alsa и пути разработки X11, определенные там (возможно, они должны быть в скриптах платформы). Я бы посоветовал для максимального воздействия, если мы хотим, чтобы accepttopenjdk был последовательно построен определенным образом, чтобы разработчики могли реплицировать большинство наших параметров конфигурации по умолчанию, которые влияют на то, как построен OpenJDK, должен быть здесь (или один из сценариев, называемых из него)

Понимание того, где вносить изменения в сценарии сборки в целом, также является частью https://github.com/AdoptOpenJDK/openjdk-build/issues/957, но я создаю это, чтобы немного ограничить объем, чтобы прояснить эту важную проблему.

documentation enhancement help wanted

Источник

sxa

👍1

Все 6 Комментарий

У нас также была проблема с разделением наших файлов между репозиториями, я думаю, это поможет ...

karianna 8 окт. 2020

👍1

Меня не слишком убедила такая фрагментация, но независимо от того, что нам нужно будет решить, что и где должно быть, и документирование этого было бы тривиальным первым шагом (ну, решение было бы хорошим первым шагом, тогда мы сможем задокументировать)

sxa 9 окт. 2020

Параметры конфигурации, установленные как в build.sh, так и в сценариях groovy, должны быть объединены в сценарии платформы, и я думаю, что затем сценарии следует переместить в makejdk-any-platform.sh. Передача одного флага (например, --use-default-config-args) может вызвать их, или пропуск этого флага отключит их (так что сценарии используют только аргументы конфигурации пользователя).

Это хорошая идея, потому что:

Будет только одно место, где заданы аргументы конфигурации, что упростит их поиск и изменение.
Перемещение скриптов платформы в makejdk-any-platform.sh означает, что сборка докеров с использованием наших образов докеров должна клонировать только одно репо (после того, как мы закончим разделение репозитория сборки).
Пользователь может запустить makejdk-any-platform.sh без необходимости устанавливать какие-либо аргументы конфигурации и быть уверенным, что конфигурация сборки будет иметь все необходимые параметры, если они используют один из наших файлов докеров для сборки.
Мы можем установить «диапазоны» версий для каждого аргумента конфигурации, вместо того, чтобы копировать одни и те же файлы конфигурации для каждого выпуска. Это означает меньше файлов, меньше дублирования кода, а также уменьшает количество вещей, которые могут пойти не так, когда мы готовимся к новым версиям OpenJDK.

adamfarley 4 дек. 2020

Когда я попытался реализовать действие build-jdk, я начал с readme и использовал makejdk-any-platform.sh для сборки jdk, что означает, что конфигурации, зависящие от платформы, невидимы.

Мне было интересно, можем ли мы перемещать файлы в конфигурациях для конкретной платформы, чтобы они соответствовали уровню build.sh, чтобы jenkins, действия git-hub, пользователи для сборки jdk изначально и т. Д., Независимо от того, какая это среда системы сборки, также могли использовать Это? Я полагаю, что эти конфигурации для конкретной платформы зависят от платформы, а не от Дженкинса.

Скрипты Groovy - это скрипты сборки jenkins, которые будут разделены на отдельные репозитории https://github.com/AdoptOpenJDK/openjdk-build/issues/1108?

sophia-guo 7 дек. 2020

👍1

Параметры Groovy jenkins были уточнены в README.md репозитория jenkins через https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67. Теперь у пользователей должно быть хорошее представление о том, какие параметры доступны и где следует создавать новые. # 2506 регулирует FAQ на этой стороне проекта.

Теперь я намерен настроить FAQ этого (openjdk-build) репозитория, чтобы уточнить, что конкретные параметры jenkins должны быть выполнены на https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/67, где параметры на основе машины и глобальные параметры должны быть указаны в файлах платформы и build.sh соответственно

M-Davies 3 мар. 2021

https://github.com/AdoptOpenJDK/openjdk-build/pull/2518 был объединен, что завершает внесение изменений в документ. Это должно справиться с любым, кто хочет добавить новые параметры в проект. Заключительная часть этого вопроса будет заключаться в изучении наших существующих параметров и местоположений, оценке каждого из них на предмет его применимости в его текущем местоположении и, на основе этой оценки, необходимости их перемещения в другое место. Однако это будет большая работа, и у меня вряд ли будет время выполнить эту задачу в разумные сроки, учитывая несколько задач с более высоким приоритетом, с которыми я работаю в данный момент.

Таким образом, я удалю свое назначение и предоставлю кому-нибудь другому возможность повторно оценить наши существующие параметры.

M-Davies 10 мар. 2021

👍1

Была ли эта страница полезной?

0 / 5 - 0 рейтинги