Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Как заставить дженкинс не апдейтить конкретный файл


(Виталий Коряков) #1

Добрый день.
Проблема следующая: есть файл с ключами, который меняется с прохождением теста. На следующий круг дженкис апдейтит репозиторий, и забирает “старую” версию файла, который изменился на виртуалке дженкисна.
Что можно сделать, что бы дженкинс не апдейтил конкретный файл с ключами?


(Vasiliy Rakshin) #2

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


(Sergey Korol) #3

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

Предоставьте больше данных - посмотрим, что можно изменить в вашем флоу.


(Виталий Коряков) #4

Тестируется апишка использования ключей. Ключи одноразовые, поэтому для каждого теста нужны новые. В файле собрана пачка ключей для тестов, откуда для каждого теста забирается первый ключ, удаляется из файла, и т д по кругу. Поэтому и файл постоянно меняется.
Может другой алгоритм будет более верным?


(Sergey Korol) #5

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


(Виталий Коряков) #6

Ключей нагенерено на 5 лет вперед, нам не жалко )))
Дергать генератор - это писать более емкий тест и поднимать вебдрайвер, совершенно другая структура. Тут же делается все на уровне апи - запрос/ответ.
Поэтому файл с ключами - было отличным решением, пока не столкнулся с этими нюансами в Дженкинсе.


(Sergey Korol) #7

Если генератор дергается webdriver’ом, значит он находится в web’е, так? Так. Если он находится в web’е, значит вероятней всего у него торчат наружу endpoints, которые можно легко дернуть любым HTTP / REST и т.п. клиентом, чтобы получить новый ключик, так? Так. Если вы уже работаете на низком уровне, что мешает точно на таком же уровне обратиться к генератору?

П.С. Это можно все провернуть даже на уровне DataProvider, чтобы в тесте иметь уже готовенький ключик еще до запуска.


(Виталий Коряков) #8

Да, это как вараиант.
Уже обсудили с тим лидом, способ не совсем подходит для нашей инфраструктуры, придется дописывать еще одну апишку. Но вцелом да, это выход.
Спаисбо )


(Stan) #9

а почему просто не добавить файл в .gitignore?


(Виталий Коряков) #10

А что в этом случае будет игнориться? Файл в репозитории, откуда Дженкинс его забирает, или файл на виртуалке где Дженкинс запускает тесты?
Необходимо, что бы файл был именно на виртуалке, но настроено именно так, что перед каждым запуском Дженкинс забирает файлы с репозитория

Ну и еще проблема - там СВН )))


(Stan) #11
svn propset svn:ignore "file.txt" 
  1. кладете файл на виртуалку миллионом разных способов (от pre-configured workspace, до тупо wget откуда-либо или до копирования артефакта из соседней джобы)
  2. удаляете файл из репозитория (ибо зачем он там вам там нужен - непонятно, т.к. вы его все равно не версионируете)
  3. чекаутите репу, файл остался, гит-свн его не видит

В крайнем случае можно заигнорить чисто на чекаут:

git update-index --assume-unchanged file.txt

если свн, то в два приема: http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html


(vmaximv) #12

Как вариант - не удалять ключи.
Сформировать xml/json/csv - что ближе. Две колонки - key | isUsed.
Использовали ключ - поставили признак.
После тестов лейте файл в git svn.