Не очень представляю твой юзкейс... Но звучит жутковато

добрый вечер. а кто нибудь попробовал сделать авто релиз flutter ios в app store ?

почему жутковато?
Отделять логику от данных вполне очевидное решение как по мне. Когда данных не много, можно и в коде держать. Но по сути это же конфиг, не понимаю что жуткого в том чтобы вынести это в текстовой конфиг

def jobs = [
    [
        name: 'job1',
        repo: 'https://github.com/example/repo',
        pipelinePath: './jenkins/android.groovy',
        envs: [
            // some environments
        ],
        parameters: [
            // some parameters
        ]
    ],
    [
        name: 'job2',
        repo: 'https://github.com/example/repo',
        pipelinePath: './jenkins/ios.groovy',
        envs: [
            // some environments
        ],
        parameters: [
            // some parameters
        ]        
    ],
    [
        name: 'job3',
        repo: 'https://github.com/example/repo',
        pipelinePath: './jenkins/web.groovy',
        envs: [
            // some environments
        ],
        parameters: [
            // some parameters
        ]        
    ],
....    
]

jobs.each { job ->
 // some code
}

вынести jobs в статический текстовой файл(например yaml) мне кажется логичным.

jobs:
 - name job1
   repo: https://github.com/example/repo
   envs: 
      ....

1) Удобство: вычещаем из кода конфиги, в коде остается только логика
2) Другой человек будет править yaml или json, с ним ему будет проще и вероятность сломать код гораздо ниже

ну, это и получается jjb в чистом виде

- job:
    name: job-name
    project-type: pipeline
    description: job-description
    parameters:
    - string:
        name: MY_PARAM
        default: MY_VALUE
   dsl: !include: pipelines/job-name.groovy

что касается данных(конфигов) да, но только с гораздо более простой структурой и с меньшим количеством полей. Но код еще же есть, там можно фигачить нужную мне логику на полноценном яп. В jjb ты сильно ограничен в этом плане, + jjb позволяет некоторую логику делать - что плохо и этого может быть недостаточно, данные должны отсаваться данными мне кажется, а логика работы с ними, отдельно

но в целом я до сих пор думаю а не перейти ли на jjb. Но боюсь что чего-то может не хватит. Иногда хочется просто написать код, чем выяснять как натрюкачить с синтаксисом чтобы получить что хотел.

job.yaml:

- job:
    name: job-name
    project-type: pipeline
    description: job-description
    parameters: !include: params.yaml
    dsl: !include: pipeline.groovy

params.yaml:

- string:
    name: MY_PARAM
    default: MY_VALUE

не понимаю, чего ты хочешь достичь

Ну я не хочу вот эту  магию видеть в ямле !include: params.yaml
В этих структурах легко ошибиться, +  !include: params.yaml  - это уже не синтаксис ямл, а логика в jjb видимо. Если нужна какая-то логика в конфиге то я возьму jsonnet, не хочу использовать специфический синтаксис jjb. jsonnet как никак общая технология, а jjb специализированный инструмент.

Я не хочу писать полноценные структры из API jjb. И хочу оставить возможность влиять на логику. Я не хочу держать логику в конфигах

Например мне не нужно

      scm:
        - git:
            url: http://example.org/test_job.git

мне достаточно repo: 'http://example.org/test_job.git'
не нужны и такие штуки:  
distributions: !!python/tuple [precise, jessie],

а вот это еще веселей:
architectures: !!python/tuple &architectures
- amd64
- x86
спец конструкция которую понимает jjb ( !!python/tuple) + якорь из синтаксиса ямла (&architectures)

При этом есть job dsl на котором можно накручиать любую логику.
В теории я такую обертку над jjb могу сделать. Генерить конфиг  jjb через jsonnet, вместо использований !include, job-template и подобного. Но наверное остановлюсь пока на конфигах и job dsl

jsonnet я ковырял только в рамках grafonnet
мягко говоря, не понравилось

мне нравится, хороший способ переиспользовать конфиги и крутить ими как тебе надо

Привет. Можешь поделиться своим решением?

Привет. Так ниже написал

в пайплайн степсах можно вызывать джобДСЛ

https://www.jenkins.io/doc/pipeline/steps/job-dsl/

существует ли какой-то способ повесить таймаут только на процесс занятия ноды? timeout(60) { node(x) { ... } } — не то, я не хочу внешним таймаутом огораживать внутренний скоуп. Хочется чего-то в духе node(label: x, timeout: 60) или хотя бы timeout(60) { node(x) { parentTimeout.cancel()

прискорбно(

Здравствуйте! Прошу открыть заявку для доработки Jenkins 2.277.2
при установке на линукс не  добавляются права на запись на /tmp и не указывается командная оболочка.
это приводит к тому, что в случае доступа к репозиторию исходного кода по ssh пользователи затрачивают кучу времени на то, чтоб выявить эти недостатки и устранить.

Это вам к клаудбис а не сюда создайте ишью на гитхабе если считаете что это баг

по дефолту у всех есть запись в /tmp
что за ось? Вероятнее всего там накрученно что то

java.vm.version  11.0.11-ea+4-post-Debian-1