Комментарии 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 уже полгода живут — и даже для тулов видны шероховатости системы невооруженным глазом. Для реального продукта многие могут стать или значительной головной болью или вообще стоппером.
+1
По личному опыту, настроить базый flow довольно легко в любой CI системе. Самое интересное начинается потом :)
+1
Я по-прежнему на старом добром Jenkins.
0
Спасибо за комментарии!
1. Версионирование, конвеншнл, семвер
Честно — не слышал. Да, так, конечно, правильнее будет.
2.
> Докер, переносимость, не, не слышали?
Непонел. Для минимального проекта образа от MS вполне хватает; если есть зависимость на тулы кроме дотнета — да, надо собирать свой образ со всем необходимым тулингом, но для обычного пет-проекта в большинстве случаев должно хватать и стандартного образа.
3. Срок хранения артефактов
Тут в артефакты вынесены результаты сборки не для того, чтобы их потом скачивать пользователям — для них есть пакеты в фиде. Если появляется необходимость публиковать что-то через артефакты, то 1) можно им настроить срок хранения, да, 2) можно их скопировать поближе к корню, чтобы юзерам не продираться через 100500 папок. Но опять же, в статье — о том, как собрать либу в пакет и отправить в фид.
4. Защищенные шаги
Буду признателен ссылке на документацию. Хранить токен в переменной — такое себе решение, на azure это, на мой взгляд, лучше настраивается
5.
> Ну и не хватает отдельных проверок
Да, согласен, можно настроить пре-коммит, и вообще можно много интересного сделать для процесса. Только код-стайл и многие другие проверки, я считаю, должны выполняться до коммита, чтобы не было возможности даже пушнуть что-то не то.
1. Версионирование, конвеншнл, семвер
Честно — не слышал. Да, так, конечно, правильнее будет.
2.
> Докер, переносимость, не, не слышали?
Непонел. Для минимального проекта образа от MS вполне хватает; если есть зависимость на тулы кроме дотнета — да, надо собирать свой образ со всем необходимым тулингом, но для обычного пет-проекта в большинстве случаев должно хватать и стандартного образа.
3. Срок хранения артефактов
Тут в артефакты вынесены результаты сборки не для того, чтобы их потом скачивать пользователям — для них есть пакеты в фиде. Если появляется необходимость публиковать что-то через артефакты, то 1) можно им настроить срок хранения, да, 2) можно их скопировать поближе к корню, чтобы юзерам не продираться через 100500 папок. Но опять же, в статье — о том, как собрать либу в пакет и отправить в фид.
4. Защищенные шаги
Буду признателен ссылке на документацию. Хранить токен в переменной — такое себе решение, на azure это, на мой взгляд, лучше настраивается
5.
> Ну и не хватает отдельных проверок
Да, согласен, можно настроить пре-коммит, и вообще можно много интересного сделать для процесса. Только код-стайл и многие другие проверки, я считаю, должны выполняться до коммита, чтобы не было возможности даже пушнуть что-то не то.
0
Непонел. Для минимального проекта образа от 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-сторону этих проверок, и вообще ортогонально, что там на стороне разработчиков и хуков.
0
Ох, сколько мышкокликанья, терраформа на вас нет.
0
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.
0
Непонятна озлобленность некоторых читателей…
Понятно же, что Hello world в любой области нужно начинать с простых базовых вещей.
По мере набора мышц, будет и усложнение.
Понятно же, что Hello world в любой области нужно начинать с простых базовых вещей.
По мере набора мышц, будет и усложнение.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство по CI/CD в GitLab для (почти) абсолютного новичка