Comments 9
По личному опыту, настроить базый flow довольно легко в любой CI системе. Самое интересное начинается потом :)
>Версионирование пакетов
Что насчет Conventional Commits + SemVer? Зачем руками поддерживать то, что может делать машина?
А в плане CI это — еще один stage, вероятно в другом докер-контейнере, и нужно пробросить артефакты во все зависимые стадии (но тут рводе гитлаб неплохо работает, хотя есть косячки), а потом еще и запушить тэг какой-нибудь, чтобы потом найти можно было.
Докер, переносимость, не, не слышали? И так придем к сначала одному Докерфайлу с нашим окружением, а потом, когда поймем, что оно одинаковое для трех соседних тулов, выделим в отдельный репозиторий для докерфайлов со своей инфраструктурой, а потом и свой registry нужен будет, чтобы не билдить каждый раз environment в процессе билда продукта
А тут любая команда мгновенно натолкнется на gitlab.com/gitlab-org/gitlab-runner/-/issues/1057 :)
Срок хранения артефактов? По умолчанию неделя, это катастрофически мало, фиксится после первого кейса «ой а у вас ссылка битая».
Защищенные шаги? Ну там, деплоить можно только по секретному паролю и вручную? Гитлаб такое позволяет.
Ну и не хватает отдельных проверок (ну типа code style тот же, мелочевка полезная, pre-commit.com в помощь).
В общем, вы не подумайте, по сравнению с кучей недавних статей школьников тут хоть понятно, что делали и зачем, и результат неплохой, хорошая статья… Но у нас вот небольшие тулы на Gitlab CI уже полгода живут — и даже для тулов видны шероховатости системы невооруженным глазом. Для реального продукта многие могут стать или значительной головной болью или вообще стоппером.
>Версионирование пакетов
Что насчет Conventional Commits + SemVer? Зачем руками поддерживать то, что может делать машина?
А в плане CI это — еще один stage, вероятно в другом докер-контейнере, и нужно пробросить артефакты во все зависимые стадии (но тут рводе гитлаб неплохо работает, хотя есть косячки), а потом еще и запушить тэг какой-нибудь, чтобы потом найти можно было.
script:
— dotnet build -c Release
Докер, переносимость, не, не слышали? И так придем к сначала одному Докерфайлу с нашим окружением, а потом, когда поймем, что оно одинаковое для трех соседних тулов, выделим в отдельный репозиторий для докерфайлов со своей инфраструктурой, а потом и свой registry нужен будет, чтобы не билдить каждый раз environment в процессе билда продукта
artifacts:
paths:
— your/path/to/binaries
А тут любая команда мгновенно натолкнется на gitlab.com/gitlab-org/gitlab-runner/-/issues/1057 :)
Срок хранения артефактов? По умолчанию неделя, это катастрофически мало, фиксится после первого кейса «ой а у вас ссылка битая».
Защищенные шаги? Ну там, деплоить можно только по секретному паролю и вручную? Гитлаб такое позволяет.
Ну и не хватает отдельных проверок (ну типа code style тот же, мелочевка полезная, pre-commit.com в помощь).
В общем, вы не подумайте, по сравнению с кучей недавних статей школьников тут хоть понятно, что делали и зачем, и результат неплохой, хорошая статья… Но у нас вот небольшие тулы на Gitlab CI уже полгода живут — и даже для тулов видны шероховатости системы невооруженным глазом. Для реального продукта многие могут стать или значительной головной болью или вообще стоппером.
По личному опыту, настроить базый flow довольно легко в любой CI системе. Самое интересное начинается потом :)
+1
Я по-прежнему на старом добром Jenkins.
Спасибо за комментарии!
1. Версионирование, конвеншнл, семвер
Честно — не слышал. Да, так, конечно, правильнее будет.
2.
> Докер, переносимость, не, не слышали?
Непонел. Для минимального проекта образа от MS вполне хватает; если есть зависимость на тулы кроме дотнета — да, надо собирать свой образ со всем необходимым тулингом, но для обычного пет-проекта в большинстве случаев должно хватать и стандартного образа.
3. Срок хранения артефактов
Тут в артефакты вынесены результаты сборки не для того, чтобы их потом скачивать пользователям — для них есть пакеты в фиде. Если появляется необходимость публиковать что-то через артефакты, то 1) можно им настроить срок хранения, да, 2) можно их скопировать поближе к корню, чтобы юзерам не продираться через 100500 папок. Но опять же, в статье — о том, как собрать либу в пакет и отправить в фид.
4. Защищенные шаги
Буду признателен ссылке на документацию. Хранить токен в переменной — такое себе решение, на azure это, на мой взгляд, лучше настраивается
5.
> Ну и не хватает отдельных проверок
Да, согласен, можно настроить пре-коммит, и вообще можно много интересного сделать для процесса. Только код-стайл и многие другие проверки, я считаю, должны выполняться до коммита, чтобы не было возможности даже пушнуть что-то не то.
1. Версионирование, конвеншнл, семвер
Честно — не слышал. Да, так, конечно, правильнее будет.
2.
> Докер, переносимость, не, не слышали?
Непонел. Для минимального проекта образа от MS вполне хватает; если есть зависимость на тулы кроме дотнета — да, надо собирать свой образ со всем необходимым тулингом, но для обычного пет-проекта в большинстве случаев должно хватать и стандартного образа.
3. Срок хранения артефактов
Тут в артефакты вынесены результаты сборки не для того, чтобы их потом скачивать пользователям — для них есть пакеты в фиде. Если появляется необходимость публиковать что-то через артефакты, то 1) можно им настроить срок хранения, да, 2) можно их скопировать поближе к корню, чтобы юзерам не продираться через 100500 папок. Но опять же, в статье — о том, как собрать либу в пакет и отправить в фид.
4. Защищенные шаги
Буду признателен ссылке на документацию. Хранить токен в переменной — такое себе решение, на azure это, на мой взгляд, лучше настраивается
5.
> Ну и не хватает отдельных проверок
Да, согласен, можно настроить пре-коммит, и вообще можно много интересного сделать для процесса. Только код-стайл и многие другие проверки, я считаю, должны выполняться до коммита, чтобы не было возможности даже пушнуть что-то не то.
Непонел. Для минимального проекта образа от MS вполне хватает;
Ну как бы да, но в итоговом .gitlab-ci.yml у вас же нет указания на докер совсем. Я по-умолчанию читаю это как «shell runner» без каких либо предположений. Если вы используете дефолтовую настройку раннера, то это какая-то скрытая зависимость, лучше все-таки прямым текстом в yaml написать что-то вроде
tags:
- windows
- docker
image:
name: "my_wonderful_windows:latest"Ну и все-таки для любого проекта сложнее хелло-ворлд у вас будут зависимости, которые надо откуда-то скачать, зависимости на системные библиотеки, зависимости на тулы-запускаторы… Если вы в корпорации, то будут особые прокси. Ну что говорить, у нас на работе докерфайл для основного проекта — около 100 строк (а сам проект относительно небольшой, ну в районе десяти тысяч строк кода думаю). И это только билд-окружение, без, собственно, шагов билда.
Буду признателен ссылке на документацию. Хранить токен в переменной — такое себе решение, на azure это, на мой взгляд, лучше настраивается
Где-то тут docs.gitlab.com/ee/ci/environments.html, а именно docs.gitlab.com/ee/ci/environments/protected_environments
Только код-стайл и многие другие проверки, я считаю, должны выполняться до коммита, чтобы не было возможности даже пушнуть что-то не то.
Хуки типа pre-receive/update в общем случае не применимы вообще, потому что считаем, что у вас нет такого уровня контроля над Git сервером. Пример — в нашей компании мы используем Gitlab, но по-настоящему админский доступ ко всему гитлабу есть только у IT подразделения и они уж точно ничего специфичного для нашей команды во всем гитлабе менять не будут.
Любой пре-коммит хук на стороне клиента может быть, но вы никогда не должны полагаться на то, что его используют. Т.е. в любом случае, вне зависимости от настоящих pre-commit хуков, вы все равно должны проверять то же самое в CI. Кто-то мог забыть поставить хуки, кто-то специально закоммитил с --no-verify, кто-то коммитит из веб-интерфейса. Это как валидация данных на фронтенде и бекенде — в бекенде она всегда и в любом случае должна быть, вне зависимости от валидации на фронте :)
И я говорил, естественно, про CI-сторону этих проверок, и вообще ортогонально, что там на стороне разработчиков и хуков.
Ох, сколько мышкокликанья, терраформа на вас нет.
Note: The rules syntax is now the preferred method of setting job policies. only and except are candidates for deprecation, and may be removed in the future.
Непонятна озлобленность некоторых читателей…
Понятно же, что Hello world в любой области нужно начинать с простых базовых вещей.
По мере набора мышц, будет и усложнение.
Понятно же, что Hello world в любой области нужно начинать с простых базовых вещей.
По мере набора мышц, будет и усложнение.
Sign up to leave a comment.
Руководство по CI/CD в GitLab для (почти) абсолютного новичка