За спрос не бьют…

Коллега ушел в отпуск.

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

Ранним утром в чатик одного из проектов написал разработчик. Попросил собрать поставку и развернуть на ИФТ. "ОК", говорю. Вообще, в стандартном, беспроблемном случае, сборка поставки - это нажатие пары кнопок, выставление нескольких чекбоксов и, собственно, ожидание, когда все это дело соберется. Потому уже поставка едет дальше по конвейеру в целевую среду.

Зашел в интерфейс оркестратора и вижу, что разработчик, что обратился ко мне, уже сделал три самостоятельных попытки сборки. И все неудачные. Тут я насторожился. Потому что на этом проекте (а в идеале, так должно быть везде) разработка умеет нажимать нужные кнопки, чтобы собирать и доставлять поставки до целевых сред. Для этого, собственно, конвейер и собирался.

Понимая, что скорее всего, и моя попытка провалится, я все равно запустил сборку. Которая через несколько секунд вылетела ровно с той же ошибкой, что и у предыдущего "сборщика" - нет прав для сборки. Сразу возникло предположение, что ключ доступа к репе с исходниками приказал долго жить. Но, в этом случае, обычно, немного другая ошибка появляется - not authorized. Тем не менее, пошел я в репу, от имени ТУЗы, из под которой и происходит вся сборка.

Зашел, смотрю, а там - тишь да гладь. И вообще ключей никаких нет. Вот это номер, думаю. Куда делся ключ - разбираться не стал, времени не было. Создал новую пару.

Как и положено, открытый закинул в репу, закрытый - в credentials-переменную на стороне оркестратора. Предусмотрительно создал отдельную переменную, чтобы ничего вдруг не поломать, так как посмотреть, что там за ключ лежит в старой енве - невозможно. Только перезаписать. Жму кнопку сборки - не работает. ❌Та же ошибка.

Ладно, думаю. Может где-то ошибся, и в самом пайпе забыл новую переменную прописать. Проверил. Вроде все нормально. Все должно работать. Но не работает.

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

Его ответ почти заставил меня истерически хохотать.

"Во-первых, не меняйте название переменной с закрытым ключом", - просветил коллега. Это, если вы помните, было самым первым, что я сделал.

"И, там, кажется, нужно ключ создавать с парольной фразой, идентичной паролю самой ТУЗы", - вот тут меня уже начало корежить от смеха. Оказывается, где-то в дебрях пайплайна (а это не простой Jenkinsfile, а нагромождение скриптов, разбираться в которых - отдельная задача, не на один час) прописано это правило. И о нем не знал никто, кроме отдыхающего коллеги. Так как обычно в пайплайнах мы ключи не паролим.

Успокоившись, я поблагодарил коллегу за информацию, пересоздал ключевую пару, и все заработало.

Выводы? Очень простые. Если кого-то подменяете, пока этот человек доступен, представьте самую невероятную ситуацию, которая может случиться в его отсутствие и поймите, что вам нужно, чтобы из нее выйти. После, не стесняйтесь выглядеть маниакальным педантом, и задайте все возможные вопросы. Потому что, уходящие в отпуск люди никогда не предоставят информацию в полном объеме сами, как бы они этого не хотели - что-то всегда ускользнет.

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

#itbetween #devops #it