2015-11-06 4 views
9

Я сейчас пытаюсь пометить репо из сценария Jenkins Workflow. Я попытался использовать шаг sh, но это связано с проблемами из-за отсутствия учетных данных.Тег репо из сценария рабочего процесса Jenkins

fatal: could not read Username for 'https://<repo>': Device not configured 

Есть существующий шаг, который может быть использован либо помечать репо или обойти проблему мандатной?

ответ

16

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

Его недостаток, потому что он включал указание всего на URL, но эти значения маскируются на выходе консоли.

withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'MyID', usernameVariable: 'GIT_USERNAME', passwordVariable: 'GIT_PASSWORD']]) { 

    sh("git tag -a some_tag -m 'Jenkins'") 
    sh("git push https://${env.GIT_USERNAME}:${env.GIT_PASSWORD}@<REPO> --tags") 
} 
+1

Это ваш лучший выбор на данный момент.[JENKINS-28335] (https://issues.jenkins-ci.org/browse/JENKINS-28335) предлагает более удобную систему. –

+1

Я подтверждаю, что используя ['sshagent (['git-credentials-id'])'] (https://issues.jenkins-ci.org/browse/JENKINS-28335?focusedCommentId=269000&page=com.atlassian.jira. plugin.system.issuetabpanels: comment-tabpanel # comment-269000) работает и немного проще. Я использовал его [здесь] (http://stackoverflow.com/questions/40618449/how-to-checkout-ssh-remote-in-github-organization-and-use-ssh-credentials-in-jen) – GabLeRoux

+0

Значения могут быть замаскированы на выходе консоли, но любой, кто имеет доступ к машине, может прочитать пароль из командной строки процесса. Будем надеяться, что скоро получим безопасную альтернативу! – Gili

9

Вот альтернатива, которая не требует знания URL на пульте дистанционного управления:

try { 
    withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'MyID', usernameVariable: 'GIT_USERNAME', passwordVariable: 'GIT_PASSWORD']]) { 
    sh("${git} config credential.username ${env.GIT_USERNAME}") 
    sh("${git} config credential.helper '!echo password=\$GIT_PASSWORD; echo'") 
    sh("GIT_ASKPASS=true ${git} push origin --tags") 
    } 
} finally { 
    sh("${git} config --unset credential.username") 
    sh("${git} config --unset credential.helper") 
} 

Это работает, имея мерзавец читать имя пользователя из конфигурации, и пусть удостоверение помощника поставить только пароль. Дополнительный echo в конце - для выполнения команды, которую git передает в качестве аргумента помощнику, не заканчивается в той же строке, что и пароль.

0

Итак, я попробовал решение @ user3617723, но по какой-то причине чего-то не хватало. через некоторое время я нашел свою проблему. У меня есть верхняя работа, которая отвечает спустить GIT репозиторий и вызвать работу конвейера с моей работы скрипта, который имеет другое рабочее пространство:

//use the jenkins global credential id and create the env parametrs of GIT_PASSWORD and GIT_PASSWORD 
withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'cred-github', usernameVariable: 'GIT_USERNAME', passwordVariable: 'GIT_PASSWORD']]) { 

//change directory to the work dir with the ".git" files and create tags 
sh("cd ${MANAGER_WORKSPACE} ; git tag -a v-${props.'VERSION_NUMBER'} -m ${BUILD_URL}") 

//get only the url after the https 
giturl_push = GIT_URL.split("//")[1] 

// change directory to the work dir with the ".git" files and push the tags to the repo 
sh("cd ${MANAGER_WORKSPACE} ; git push https://${env.GIT_USERNAME}:${env.GIT_PASSWORD}@${giturl_push} --tags") 




} 
-1

Следующие работы для меня

checkout scm 

... build ... 

sh("git tag -a $branch-$buildVersion -m 'Jenkins tagging'"); 
sh("git push origin --tags") 

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

0

Вы можете создать свой собственный personal API token (OAuth) и использовать его так же, как обычные обычные учетные данные (по адресу: /settings/tokens). Например:

git tag -a some_tag -m 'Jenkins' 
git push https://[email protected]/foo/bar 
1

Если мерзавец пароль содержит специальные символы, такие как «%», «:», «@», или «/», проходящей ${env.GIT_PASSWORD} как часть мерзавца URL т.е. https://${env.GIT_USERNAME}:${env.GIT_PASSWORD}@<REPO> без выполнения кодирования вероятно, приведет к ошибке Invalid username or password.

Для сохранения каких-либо хлопот с помощью инлайн credential.helper это лучший способ пойти, однако предложение о !echo password=\$GIT_PASSWORD; echo' приведет к предупреждению их в ваших журналах warning: invalid credential line: get как credential.helper передается аргумент, чтобы указать требуемую операцию (получить, хранить, стирать). В этом случае помощник учетных данных пытается интерпретировать операцию get в качестве ввода учетных данных. Допустимыми входами являются протокол, хост, путь, имя пользователя, пароль, URL. См. https://git-scm.com/docs/git-credential#IOFMT

Лучшим встроенным идентификатором credential.helper будет !f() { echo password=\$GIT_PASSWORD; }; f Таким образом, операция credential.helper get игнорируется.

Полный пример:

try { 
    withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'MyID', usernameVariable: 'GIT_USERNAME', passwordVariable: 'GIT_PASSWORD']]) { 
    sh("${git} config credential.username ${env.GIT_USERNAME}") 
    sh("${git} config credential.helper '!f() { echo password=\$GIT_PASSWORD; }; f'") 
    sh("GIT_ASKPASS=true ${git} push origin --tags")  
    } 
} finally { 
    sh("${git} config --unset credential.username") 
    sh("${git} config --unset credential.helper") 
} 
Смежные вопросы