Jenkins - Учетные данные субмодуля Git отличаются от родительского репо

Фон

Дженкинс используется для создания артефакта из репозитория Git с подмодулем Git. Подмодуль (ы) не находятся в том же репо или даже в той же конечной точке, что и родительский проект. Проблема в том, что родительское репо работает нормально, поскольку учетные данные, ключ ssh A, связан с основным / родительским репо, но, что неудивительно, происходит сбой в подмодуле, потому что учетные данные, ключ ssh B, не связан с репо из Jenkins. ' точка зрения.

Удивительно, что у Дженкинса нет лучшей встроенной поддержки для подмодулей Git; время внести свой вклад.

Вопросы

  1. Есть ли способ хранить несколько учетных данных для одного репозитория Git?
  2. Если ответ "нет", почему Jenkins в разделе " Расширенные поведения подмодулей" предоставляет возможность использовать учетные данные из удаленного по умолчанию родительского репозитория, как показано ниже?
  3. Какой другой подход существует для работы с подмодулями Jenkins и Git с разными учетными данными?

Системная информация

Запуск Дженкинс на Docker Machine (локально)

Запуск Дженкинс на CentOS (Производство)

Версия Jenkins: 2.60.2 (оба)

Версия Git Plugin: 3.6.4 (оба)

Источник

2 ответа

  1. Нет — плагин git поддерживает только один ключ (на момент написания этой статьи)
  2. Согласно документации плагина git , поведение по умолчанию — вообще не использовать учетные данные для подмодулей. Логический флаг сообщает плагину, что вместо этого следует использовать родительские учетные данные. Плагин git, который он использует ниже, не поддерживает идею использования каких-либо других учетных данных.
  3. Это было очень сложно найти, но я столкнулся с той же проблемой в моем проекте Github — в нем использовались модули, а Github не позволяет использовать один и тот же ключ развертывания для разных проектов .

Чтобы обойти это, я сначала настроил приложение github , установил его и назначил проект и его подмодули. Это приложение способно генерировать ключи доступа, которые можно использовать для клонирования, поэтому я использовал эти учетные данные для клонирования. Я отключил подмодули в поведении плагина git и использовал собственный gitкоманда для обновления URL-адреса подмодуля для использования имени пользователя и пароля перед запуском submodule initа также submodule updateдля клонирования подмодулей.

      steps {
    withCredentials([usernamePassword(credentialsId: 'github-app-credentials',
                                usernameVariable: 'GITHUB_APP',
                                passwordVariable: 'GITHUB_ACCESS_TOKEN')]) {
        checkout ([
            $class: 'GitSCM',
            userRemoteConfigs: [[
                credentialsId: '',
            url: "https://x-access-token:$GITHUB_ACCESS_TOKEN@github.com/<ORG>/<PROJECT>.git"
            ]],
            branches: [[ name: '*/main' ]],
            extensions: [[
                $class: 'SubmoduleOption', 
                disableSubmodules: true
            ]]
        ])
        sh '''
            git config --file=.gitmodules submodule.SUBMODULE_A.url https://x-access-token:$GITHUB_ACCESS_TOKEN@github.com/<ORG>/<SUBMODULE_A>.git
            git config --file=.gitmodules submodule.SUBMODULE_B.url https://x-access-token:$GITHUB_ACCESS_TOKEN@github.com/<ORG>/<SUBMODULE_B>.git
            git submodule init update
            git restore .gitmodules

            # rest of build
        '''
    }
}

Это указывает на проблему безопасности в Jenkins, поскольку GITHUB_ACCESS_TOKEN интерполируется в строку, чтобы передать ее URL-адресу git. Я не верю, что это поправимо, так как checkoutкоманда не будет ссылаться ни на одну переменную среды. Однако похоже, что эти токены доступа эфемерны, поэтому это несколько смягчается.

Я полагаю, что вы также можете использовать ключи развертывания, любезно используя переменную окружения GIT_SSH_COMMAND , хотя это остается читателю в качестве упражнения.

В следующий раз, когда кто-то предложит использовать подмодуль git, пожалуйста, нажмите на него.

Источник

Да, это легко сделать. Вы можете создать пару паб / закрытый ключ и установить ее как ключ развертывания github (если вы используете git hub, если нет, то как ключ, установленный во всем, что вы используете). Вы можете добавить это как учетные данные Jenkins (при условии, что у вас установлен плагин учетных данных).

Username: git@github.com
Private Key:  the private key for that key set
Passphrase:  whatever passphrase you used
ID: aws-jenkins-github-deploykey (just an example name)
Description: some useful text

Идентификатор соответствует учетным данным ниже

checkout changelog: true, poll: false, scm: [$class: 'GitSCM',
     branches: [[name: "branch name, commit sha, or tag/tagname" ]],
     userRemoteConfigs: [[
     credentialsId: 'aws-jenkins-github-deploykey',
     url: 'git@github.com:myorg/myrepo.git']]]

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

Таким образом, вы можете использовать это, чтобы оформить кучу репозиториев и использовать для них специальные ветки.

Источник
Другие вопросы по тегам