Новая версия GitLab 8.9

https://about.gitlab.com/2016/06/22/gitlab-8-9-released/
  • Перевод
Этот текст — перевод релизного поста из блога ГитЛаба. Перевод подготовлен компанией Softmart. Мы понимаем, что наш перевод далек от идеала, но считаем что даже такой перевод будут полезен многим, кто не владеет английским языком в достаточной мере. Иван Немытченко — nem — евангелист ГитЛаба по мере возможности редактирует текст. Если вы готовы предложить свою помощь в переводе статей, будем только рады. Спасибо за понимание!

С GitLab 8.9 комфортнее работать в больших сложных проектах. Блокировка файлов, назначение приоритетов меткам, гибкие настройки уровня вовлеченности в проект, и возможность запретить объединение веток(merge) до момента, пока билд не выполнится успешно. В GitLab CI теперь можно указывать среды(production, staging, и т.д.) и задавать срок хранения артефактов. Появились шаблоны настроек CI, так что начать им пользоваться теперь еще проще.

Персона месяца(MVP) — Руи Сантос. Он разработал возможность ограничивать обьединение веток до прохождения билда. Спасибо Руи!

С версии 8.8.0 добавилось 1761 коммитов, 1947 файла были изменены. Что конкретно изменилось — смотрите ниже.

Блокировка файлов (опция EE)


Репозиторий Git позволяет хранить не текстовые файлы (бинарные, например), но не может управлять изменениями в них — нельзя сравнить версии файла, нельзя объединить изменения из разных версий файла и т.д. Если допустить редактирование файла одновременно нескольким членам команды, то потом потребуется масса времени на ручное устранение конфликтов версий.

Чтобы обойти эту проблему, мы добавили возможность ручной блокировки файлов в GitLab. Блокировка файла не позволяет никому, кроме Вас, изменять определенный файл или целый каталог. Это также наглядный способ объявить, что Вы работаете над этим файлом.

Пример: Game assets


Вы разрабатываете игру. В разработке уровней игры может быть задействована куча народу. Заблокируйте файл уровня, над которым вы работаете, из интерфейса, кликнув на «Lock»:


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


Работа над уровнем закончена? Удаляйте блокировку!
Список всех заблокированных файлов в репозитории найдете в Repository → Locked Files:


Функция блокирования файлов доступна только в редакции Enterprise Edition и на GitLab.com. Мы приветствуем ваши дополнительные предложения для расширения этой функциональности.

Среды и Развертывание в CI


В предыдущей версии GitLab появилось понятие среду развертывания: среда тестирования, среда приемки и среда промышленной эксплуатации. GitLab CI позволяет настроить последовательности развертывания (цепочки переходов между средами), по в рамках которых исполнятся задачи доставки и установки изменений.
 
В новой версии 8.9 Вы можете добавить дополнительные Среды в конфигурационном файле CI  проекта (.gitlab-ci.yml). Это позволит настроить конфигурацию GitLab максимально близко к фактическому окружению проекта и наглядно отслеживать динамику развертывания в этих средах.
 



Метки с приоритетом


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



Метка с приоритетом — такая же текстовая метка, но с указанием приоритета, который влияет на сортировку объектов, которым эта метка присвоена. 

Например, самым высоким приоритетом для GitLab является P1. Если отсортировать дефекты по приоритету, то сверху отобразятся дефекты с P1, затем с P2 и т.д. Помечая метку «Безопасность» высоким приоритетом P1, дефекты, относящиеся к этой категории, автоматически получат максимальный приоритет.
 
Пользовательский тип уведомлений


Чтобы быть в курсе важных для Вас событий, мы добавили новый тип уведомлений — пользовательский.
В предыдущих версиях GitLab можно было настроить уведомления Участника (participating level), т.е.  подписаться на события в объектах, в которых Вы участвуете, или в которых Вы упомянуты. 
В новой версии 8.9 Gitlab позволяет настроить уведомления по другому принципу - отметить интересующие типы событий (новое примечание, новый дефект, закрытие дефекта, новый запрос на объединение, переназначение дефекта и т.д.)



Запрос доступа к проекту



Связь с владельцами проектов теперь доступна с домашней страницы проекта. Если вам нужен доступ к проекту, обратись к владельцу проекта, не выходя из GitLab. Запросы отображаются в секции участников проекта. Владельцу проекта отправляется уведомление.


Шаблоны gitlab-ci.yml


Модуль поддержки непрерывной интеграции CI, встроенный в GitLab, управляется с помощью .gitlab-ci.yml файла, где определяются объекты тестирования, сборки и развертывания. Чтобы упростить первые шаги по настройке этого файла, попробуйте воспользоваться готовыми шаблонами.
 
Для того, чтобы начать работу с шаблоном .gitlab-ci.yml,  создайте новый файл и назовите его .gitlab-ci.yml. Вы увидите выпадающий список названий готовых шаблонов.
 


Изменения в навигации пользовательского интерфейса



Базовая навигация по элементам проектов осуществляется с помощью верхней панели. Страницы, которые формируются специально для текущего пользователя ( дефекты, группы, активность и т.д.) теперь перенесены в новую боковую всплывающую панель.


Поддержка Универсальной 2-факторной аутентификации


GitLab теперь поддерживает стандарт универсальной 2-факторной аутентификации (u2f). Это означает, что вы можете использовать U2F ключи безопасности на Yubico, известного как YubiKeys, в качестве 2-го фактора при входе в GitLab.
 
Подробнее о поддержке u2f в нашем блоге и документации по 2-факторной аутентификации в GitLab.

Импорт / Экспорт проектов


Если у Вас несколько экземпляров GitLab, или Вам необходима резервная копия репозитория, то теперь Вы можете импортировать и экспортировать проекты целиком.

Перейдите на страницу настроек проекта, чтобы экспортировать Ваш проект. Импорт проекта можно сделать из новой страницы проекта.


Запрет объединения веток до успешной сборки


В новой версии у Вас есть возможность запретить объединение веток(merge) до момента, пока билд не выполнится успешно, Благодаря Руи Сантос.



Другие изменения


Подробнее об остальных изменениях можно ознакомиться в Changelog. Ниже приведены только наиболее значимые.

Улучшенная подсветка синтаксиса


GitLab 8.9 включает в себя первый релиз Rouge с сентября (!) с поддержкой более чем 20 новых языков, а также поддержкой новых возможностей Swift, Ruby, Python и C / C ++, а также некоторых критических исправлений ошибок для Apache, JavaScript, Objective — C и Groovy.

Award Emoji в комментариях


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

Ручное добавление Todos


Каждый дефект и запрос на объединение теперь может быть помечен как «Todo» или «Done».


Массовое присвоение меток


С функцией назначения приоритетов, метки играют все более важную роль в GitLab. Чтобы работать с дефектами эффективнее, мы добавили возможность массового присвоения меток.

Срок действия артефактов


Если Вы используете артефакты в GitLab, встроенных в CI, у Вас может накопиться большой архив старых данных. Теперь вы можете указывать срок действия артефактов путем добавления строки expire_in в свой. gitlab-ci.yml файл. Артефакты будут считаться устаревшими, после указанного периода времени.

Вы можете по-разному указывать срок действия:

3 mins 4 sec
2 hrs 20 min
2h20min
6 mos 1 day
47 yrs 6 mos and 4d
3 weeks and 2 days

Примечание: эта функция требует Runner 1.3, выпущенный одновременно с GitLab 8.9

Ключевое слово « Когда» для Артефактов


Теперь Вы можете иметь артефакты только на провал, успех или на все события.

Поведение по умолчанию такое же, как и раньше, создание артефактов только «на успех».

Примечание: эта функция требует Runner 1.3, выпущенный одновременно с GitLab 8.9

Поддержка Docker реестра Manifest V1


GitLab 8.9 добавляет поддержку Manifest V1, порожденного старыми версиями Docker (до 1.10)

GitLab Mattermost 3.1


Mattermost 3.1 отгружается в GitLab 8.9 с мульти-командными аккаунтами, переводом японского языка, Apple Watch, с модернизированными уведомлениями, новыми горячими клавишами и переключателем каналов, новыми вариантами отображения, новыми смайликами, плюс обновление для системы безопасности и многие другие улучшения.

Обновление требует ручных операций! Перед обновлением обязательно прочитайте документацию для обновления с версий до 8.9

Softmart

73,78

Компания

Поделиться публикацией

Похожие публикации

Комментарии 57
    +1
    Как морда для GIT — Гитлаб очень неплох, хотя и несколько тяжеловесен.

    Но вот как трекер — довольно убог. Поиск по тикетам работает криво, непонятно что где ищется, и ещё в этой версии 8.9 навигацию переделали так, что без 100 грамм не разберёшься.

    Попытался настроить нотификацию, при создании новых юзер — бесполезно: в документации написано одно, в программе — другое.
    Да похоже, что у них у самих всё настроено криво, потому что в их SaaS спамят нещадно.
      0
      Вообще странный комбайн. Git+трекер+ci. Причём каждый из компонентов (ну, кроме разве что обвязки гита — оно вполне неплохо) проигрывает самостоятельным продуктам в соответствующих категориях.
      Как CI-сервер — ужасно неудобен (настройка билдов правкой yml-файликов — это красноглазие 90lvl).
      Трекер — коряв и ограничен.
      Git, вроде, ещё туда-сюда, но как полезешь в его api, чтоб снаружи привязаться — неожиданные «удивлялки» на каждом шагу.
      Интеграция со сторонними компонентами — на уровне каких-то полухромых скриптиков и иногда работающих плагинов.
      В общем, на мой взгляд, разве что для мелких красноглазых команд, которые хотят всё в одном месте чисто от лени.
        +8

        1) Могу пояснить за комбайн :)
        Я поначалу как пришел в ГитЛаб, тоже недоумевал, почему в 2016 году, когда все пилят большие монолитные приложения на отдельные сервисы, ГитЛаб поступает ровно наоборот :)
        Идея именно в том, чтобы весь процесс разработки можно было вести не выходя из ГитЛаба. В идеале:


        • В чате обсудили фичу
        • Из этого же на лету создали issue
        • Поставили в план в issue board
        • Прямо в браузере закодили чего-нибудь с помощью встроенной IDE, если не охота чекаутить на локальную машину
        • Тесты прогнались в CI
        • Провели Code review в Merge Request-e
        • Задеплоили из того же CI
        • Задокументировали чего надо в Wiki

        Это то направление, куда движется продукт. Подробнее здесь. Надеюсь теперь этот комбайн начал обретать некоторый смысл для вас


        2) За счет того что CI встроен в ГитЛаб, не нужно бегать между двумя сервисами, все в одном интерфейсе, и стало возможным запилить фичу "Merge when build succeed" — т.е. не нужно бегать и проверять а прошел ли билд, чтобы смержить его руками. Поставил галку — и иди занимайся следующей фичей.


        3) Насчет CI и yml-файлов. А по-другому — это как? Я просто сам рубист, и у нас так все жизнь везде было, и это кажется очень естественным способом конфигурить. Опять же, version control для самого конфига — это же добро, не так ли?


        Мне вчера попалась презентация про GitLab CI (ее автор никак не связан с ГитЛабом) — и там в общем прямо противоположное мнение. Посмотрите.


        4) Расскажите пожалуйста, чего не хватает в трекере, и в чем корявости? По-моему за последние несколько релизов его не слабо так прокачали: Due date, веса для меток, возможность создавать скрытые iussues.


        5) Интеграция со сторонними компонентами не сопоставима, конечно, с тем же ГитХабом. Но и компания сама пока поменьше. Плюс, если можно встроить что-то в сам продукт, то приоритет будет отдаваться этому, нежели чем созданию интерфейсов для интеграции. Это как раз следствие философии компании.


        6)


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

        Ммм, так, да не так. Большинство денег компании приносят большие компании. Для них возможность одним инструментом закрыть кучу проблема — большое благо.
        Плюс им гораздо проще платить за одну тулзу, чем разбираться с ценовой политикой и политикой лицензирования десятка продуктов. Плюс потом их все еще отдельно устанавливать и интегрировать между собой.


        ГитЛаб же ставится тупо с помощью apt-get install, или что там у вас в вашей операционке ;)

          +1
          Спасибо за Гитлаб. Используем у себя в компании. Пользуемся гдето с 5 версии. И если чесно редизайны каждый год немного достали))

          Вопрос можно ли както настроить отображение субмодулей в списке файлов.
          Очень удобно это сделанно на github. субмодуль просто показывается как папка в общем списке. в gitlab субмодули находятся после всех файлов, что неудобно.
          +3

          Не холивара ради, а вот чисто со своей колокольни и с опытом использования того же gitlab.


          1) На КАЖДОМ шаге есть гораздо более гибкий инструмент. Большие компании обречены (по идее) упираться в куций функционал GitLab и


          • Строить свои бизнес-процессы вокруг GitLab (подстраиваясь под продукт, который как-бы должен удовлетворять их нужды)
          • Выносить часть функционала в другие приложения и в этом месте получать полный букет несовместимостей.

          Под несовместимостями я имею виду почти полное отсутствие поддержки GitLab со стороны других продуктов (это, мол, ещё кто такие?), вялую/обрывочную поддержку этих продуктов средстванми самого GitLab (оно и ясно — за всеми не угнаться) и мутный/нелогичный API, на который завязываться сам одуреешь.


          2) Эта "убер-киллер-фича" есть где угодно. Да хоть в Bitbucket том же. В TeamCity есть automerge емнип.


          3) А у нас в разработке ruby вообще нигде рядом не валялся и лезть ещё и в эту фигню ради CI ну вообще ни разу не логично. Когда разработчик ещё и сам себе CI/CD строит — это неразумное использование ресурса этого самого разработчика.


          4) А если сравнить с кастомным workflow в Jira, хотя бы?
          В общем-то все наши потуги с GitLab закончились именно по причине слишком кривой и муторной интеграции с уже имеющейся и работающей JIRA. Вернее, интеграция заканчивается на парсинге JIRA IssueID и замене их на ссылку. Вот и вся интеграция.


          5) Самое смешное в этой интеграции — это gitlab rest api. Он так старается копировать GitHub API, но при этом местами отличается. Т.е. всё, что делается под GitHub, могло бы работать и с GitLab, если бы не "там слово другое, тут те же статусы называются иначе" и т.п.


          ps: Личная обида: мой pull-request на Commit status publisher для TeamCity с поддержкой GitLab провисел у них месяца два, после чего был закрыт со словами "мы это, так и быть, запилим в 10й версии, а вы со своим TeamCity 9 сидите как хотите".
          Со стороны Atlassian Confluence/Jira в сторону GitLab всё вообще ужасно.
          Для меня это некий общий показатель отношения к продукту, так что о какой-то интеграции можно даже не заикаться. Он не нужен и не интересен никому, кроме вас самих. А вы не спешите дружить с другими системами именно из-за идеологии "у нас свой комбайн".

            0

            Я разрабатываю на джаве и у нас тоже ямлы всюду… Думал уже стандарт для конфигурирования де факто…

              0

              Спасибо за ваше мнение. Я думаю что продукты нужны всякие.
              И видимо ГитЛаб просто не подходит для ваших нужд и вашего процесса разработки.


              C Jira трекер ГитЛаба сравнивать не надо. Это очевидно продукты в совершенно разной весовой категории. Если уж сравнивать, то с ГитХабом.
              P.S. я надеюсь что ГитЛабовский трекер никогда не превратится в Jira. Это было бы печально.


              Вы кстати какую версию интегрировали с Jira? В Community edition полная поддержка Jira появилась только в 8.3: http://docs.gitlab.com/ce/project_services/jira.html


              ГитЛаб — сравнительно молодой продукт, и было бы странно расчитывать на такую же его поддержку как и ГитХаба. Но это плавно меняется, кстати говоря. Ваш пример — тому подтверждение. +Картинка с google trends:


                0

                Если мне не изменяет память, то 8.4, 8.5, 8.6, а потом забили окончательно. сейчас часть проектов доживает в 8.6.5 (чисто как обёртка над гит), но вся разработка оттуда вынесена уже к чертям, чтоб больше не пинать этот труп.


                Да я не спорю. Совершенно стандартная ситуация с комбайнами и выделенными решениями. Либо ты подстраиваешься под комбайн, либо подстраиваешь всё сам под себя.

                +1

                Вдогонку про "интеграцию" с JIRA, сегодняшнее :) уж очень умилило.
                image


                это, если что, 12 коммитов, к каждому был указан ID задачи. собрать и сгруппировать — не судьба, видимо.
                (да, мне лень заводить тикет по продукту, который мне уже не интересен, поэтому картинка тут, а не на gitlab.com)

                0

                3) Вы так и не ответили на вопрос "А чем конфигурить то"?


                У Jenkins Jenkinsfle на groovy, у travic тоже yml.


                У остальных в основном просто скрипты.

                +1
                Расскажите пожалуйста, чего не хватает в трекере

                Нет (или не нашёл) возможности создавать вложенные задачи хотя бы на одном уровне. Нет (или не нашёл) возможности настраивать воркфлоу задачи, как-то отслеживать прогресс её исполнения.

                Не, можно, конечно, в дескрипшене создать список подзадач и отмечать там их исполнение, и метками манипулировать, отмечая статус задачи, но не удобно, а потому никто этим не занимается.
                  +1

                  Да, обычно в описании просто создается список задач: https://gitlab.com/gitlab-org/gitlab-ce/issues/14838
                  Мне нравится идея для задач, где в описании есть такие списки, показывать процент выполненного на основе проставленных галочек. Запилю feature request, если этого еще нет в планах.


                  А какие у вас статусы у задач и для чего вы их используете? Интересно какой у вас процесс разработки.

                    0
                    Да, приходится так эмулировать отсутствующую функциональность, но:

                    — связь просто на уровень встречных гиперссылок, создаваемых вручную. То есть создаёшь одну задачу, потом вторую, а потом проставляешь в них ссылки друг на друга. Никакой поддержки со стороны системы нет. И неудобно, и можно просто забыть, и ошибиться.

                    — в общем списке задачи всё равно вываливаются на одном уровне, что не позволяет хотя бы приблизительно оценить количество глобальных задач в работе

                    — нет оценки требуемого времени, дью дейт — не совсем-то, особенно для вложенных задач. Не у всех процесс разработки привязан к дедлайнам или вехам, есть ASAP. Часто ситуация, когда разработчик даёт оценку нужного ему времени, задаче назначают приоритет (в идеале точечно), когда более приоритетные задачи кончаются, разработчик приступает к задаче, если вдруг приходит более приоритетная, то он текущую откладывает, фиксируя (в идеале полуавтоматом) уже потраченное время, а потом возвращается. Так же автоматом фиксирует время при закрытии. Ну и если видит, что задача оказалась сложнее, то корректирует эстимейт (как вариант просит менеджера это сделать).

                    Глобальных статусов немного:
                    — new
                    — research
                    — development
                    — testing
                    — acceptance
                    — closed
                    но на почти каждый хотелось бы подстатусы:
                    todo
                    in progress
                    suspend
                    rejected

                      0
                      Первый список статусов вполне узнаваем. Но не задач, а требований или user-story, кому как нравится.
                      Второй список статусов часто встречается для описания процесса (workflow) управления задачами.
                      Для управления большим количеством задач и исполнителей важна иерархия задач. Для управления разработкой нескольких продуктов множеством команд аналитиков, разработчиков, тестировщиков одними задачами не обойтись — нужны типы объектов управления со своей иерархией и своим workflow. Для этого и нужны отдельные продукты Jira, RedMine, SBM.
                      Реализация таких сложных сущностей и отношений в GitLab может получиться слишком громоздкой. Где грань?

                        0
                        Ну, как по мне, не нужно создавать новые типы объектов, но можно добавить поля и UI к ним для связи существующих issue и/или todo между собой и возможность создавать произвольные статусы а не только open/closed todo/done

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

                        В догонку. Не знаю насколько это подойдет к вашему процессу, но на следующий релиз запланирован встроенный в ГитЛаб issue board:


                        Возможно это закроет некоторые из ваших нужд. А вообще есть подозрение, что для вашего процесса вам нужен чуть более сложный инструмент, чем GitLab issues, что и предложил aionin. Я, например, сомневаюсь что появится трэкинг времени в ГитЛабе.


                        Ну или подумать над упрощением процесса. Большинство описанных вами статусов будут по сути дублировать определенные состояния в системе:


                        • new — тикет создан, но ни на кого не навешан
                        • research — тикет на кого то навешан, но не создан MR
                        • development — создан MR с пометкой [WIP]
                        • testing — MR перевешан на тестировщика, из названия MR убран [WIP]
                        • acceptance — MR перевешан на code reviewer-а
                        • closed — MR смержен, тикет закрыт
                          0
                          Следующий, это уже 8.11? Обязательно попробуем. Спасибо
                            +1
                            Практически идеальный, на мой взляд, треккер в Redmine — тем, что очень гибко настраивается и интегрируется со всем, чем угодно (git, jenkins, даже с IDE) и расширяется плагинами.
                            И неплохой коробочный вариант в worksection.

                            Идея комбайна (code version, таск, ci,...) — очень правильная, но если это какой-то конкретный комбайн это будет не удобно. Нужна кастомизация и настраиваемый процесс. Кто-то работает по часам, а кто-то аджайл. Нужны предустановки, либо возможность настроить свой процесс.

                            А так очень хороший продукт, приятно смотреть, как развивается.
                        +1
                        Да, поэтому приходится прикручивать redmine. Очень хочется что бы когда-нибудь появилась возможность разбивать на подзадачи.
                          0

                          Насчет прогресса — понял, что это уже реализовано:



                          Сам тикет здесь

                        +1
                        Но ведь в travis также все делается через yml файл настроек, в гитлабе очень грамотно сделана поддержка билдов на докере — можно все запустить локально, а сам файл yml оставить на уровне команд для запуска.
                          –1
                          (настройка билдов правкой yml-файликов — это красноглазие 90lvl)

                          В Jenkins 2 тоже добавили Jenkinsfile

                          +3

                          Привет, я из ГитЛаба, если что. Я правильно понял что при всех этих недостатках вы таки пользуетесь ГитЛабом?
                          Буду рад, если получится помочь. По-порядку:


                          1. Тяжеловесность — известная проблема. Знаем про нее и активно работаем над этим


                          2. Поиск. У вас GitLab CE? С MySQL или PostgreSQL? Было бы здорово услышать конкретный сценарий использования — что где пытались найти и не получилось — тогда смогу донести фидбэк до команды.


                          3. Навигация. Редизайн — это всегда больно бля пользователя, увы. Но на привыкание уходит не так много времени, как кажется поначалу. Причина редизайна — поскольку функционала у ГитЛаба много, боковая панель была перегружена. И хоть к ней все к такой привыкли, для тех кто впервые видел ГитЛаб это было тяжело.


                          4. Нотификации. Будет круто, если кинете в меня ссылкой на устаревшую документацию — смогу отследить чтобы ее проапдэйтили.


                          5. Спам — это проблема. Но пока возможность пожаловаться на юзера решает проблему — спам аккаунты закрываются в течение дня-двух. Альтернатива — считать всех пользователей по умолчанию спамерами, и просить вводить капчу. Надеюсь до этого не дойдет. А спамеры как-то прямо вас тревожили на GitLab.com?
                            +1
                            Ну в первую очередь — спасибо за Гитлаб. При всех недостатках — да, это лучшее, что я вижу по совокупности функциональности.

                            У меня стоит Gitlab CE

                            *Нотификации*:
                            — Я хочу открыть регистрацию, чтоб люди могли приходить и писать feature requests. Но боюсь спама. Поэтому я хотел, чтобы мне приходили нотификации, когда создаётся новый пользователь. И вот тут
                            http://docs.gitlab.com/ce/workflow/notifications.html
                            написано, что вроде бы есть такой `event`: «New user created»
                            Но найти это у себя в Гитлабе я при всём старании не смог.
                              +1

                              Верните старую менюшку, пожалуйста!

                              0

                              Так, чота отвык я от Хабра. Сейчас буду разбираться как тут все работает заново

                                0
                                Кстати, не подскажете, какой общий подход к тому, чтобы CI настроить так, чтобы job могла деплоиться в одну из нескольких ENVs по выбору?

                                Вот сейчас у меня Jenkins, и я сделал там LISTBOX, из которого я выбираю DEV, STAGING,… и запускаю job. А в Гитлабе накиких LISTBOX добавлять вроде бы нельзя. Получается, что перед каждый запуском надо редактировать job variables? Или есть какой-то более прямой путь?
                                  0

                                  Можно прописать чтобы в staging деплоились все ветки кроме master. А в production — только master. Это делается с помощью опций only и except. Кусок конфига:


                                  `
                                  staging:
                                    stage: deploy
                                    script:
                                    - deploy somehow --staging
                                    except:
                                    - master
                                    environment: staging
                                  
                                  production:
                                    stage: deploy
                                    script:
                                    - deploy somehow --production
                                    only:
                                    - master
                                    environment: production
                                  `

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


                                  Плюс в последнем релизе появилась возможность в конфиге можно указать when: manual и руками запускать деплой, когда надо:

                              0
                              > Блокировка файла не позволяет никому, кроме Вас, изменять определенный файл или целый каталог.

                              Да здравствуют фразы: «Отдай каталог/файл!», «Да я быстро», «Ой, я забыл блокировку снять» и т.д.
                              Гит изначально был придуман, чтобы избежать данной проблемы. Зачем вводить эту сомнительную фичу?
                                +2

                                В переводе пропустили пример про Game assets, объясняющий зачем нужна эта фича. Я вернул этот блок в статью.
                                Эта штука важна для разработчиков игр, и тех, кому приходится держать в репозиториях бинарные файлы.

                                0
                                Использую Gitlab CE как на работе, так и для своих проектов. Продукт очень качественный. Не знаю за что ругают Gitlab CI, как по мне так он идеален. И то что runner'ы можно на нескольких серверах быстро развернуть, и артефакты теперь можно хранить заданный промежуток времени, и зависимости указывать, и конфиг удобный. Единственное что напрягает в новой версии — навигация. Реально стало не понятно и не удобно. Боковая панель стала для меня бесполезной.
                                  0

                                  Спасибо за фидбэк! На самом деле то что боковая панель стала бесполезной — это отлично. Значит цель редизайна достигнута. Все что должно быть под рукой переехало наверх.


                                  Вот пост автора ГитЛаба про редизайн: https://about.gitlab.com/2016/06/06/navigation-redesign/

                                    0
                                    Единственный недочет с которым мы столкнулись используя gitlab ci, что он запускает все задачи на каждый push например может произойти такая ситуация: делаем пуш — прошли тесты — начался деплой, в это время пришел еще один пуш и начался параллельно второй деплой. нету возможности встать в очередь и приходиться реализовать самому блокировку от паралельных деплоев.
                                +2

                                1) Хочется интеграции с Jenkins, ибо Gitlab CI — недоделка.
                                2) Как Git, работает нормально, нареканий нет. Кроме идиотского "merge when builds", которое пришлоссь отрубать из-за Gitlab CI.
                                3) Понятно, то никто не пользуется Issues, вам бы взять Redmine и JIRA хотя бы проинтегрировать, было бы СЧАСТЬЕ.

                                  0

                                  1) Привет. А расскажи, чего по твоему не хватает в GitLab CI? Я сейчас как раз работаю над статьей про него.


                                  2) Что не так с "merge when builds"? Я правильно понял что вы не пользуетесь CI, и эта фича как-то мешала вам?


                                  3) Я думаю что "никто" — это все таки преувеличение. Понятно что если у вас уже есть issue трэкер, которым вы пользуетесь годами, переезжать на новый — трудозатратная процедура. Насколько я знаю, интеграция с Jira есть, я правда сам не пробовал ее. Можете рассказать что в ней не хватает?

                                    0
                                    У меня были пара проблем с gitlab-ci

                                    1) При интенсивном выводе в stdout очень сильно тормозил браузер при просмотре лога работы тестов
                                    2) При использовании кеширования (cache в gitlab-ci.yml) и одновременном запуске двух билдов похоже, что для второго билда кеш не используется (соответственно выкачивается всё что можно из интернета)
                                      0

                                      Создал issue на (2):https://gitlab.com/gitlab-org/gitlab-ce/issues/20477
                                      Мне кажется я тоже подобное замечал. Спрошу у ребят из команды CI сегодня про это.


                                      По (1) — маловато информации для создания issue имхо. Вот бы чуть побольше деталей: какие команды выполнялись, может пример лога, или ссылка, если проект публичный.

                                        0

                                        Выяснил что чтобы работало (2), нужно настроить sharing между раннерами с помощью S3-based кэша

                                      0

                                      Используем GitLab + Redmine + Jenkins на команду ~10 человек


                                      1. Jenkins через https://github.com/jenkinsci/gitlab-plugin. В последних версиях его наконец допилили, работает вполне пристойно. Поддерживает все фичи вроде merge when build succeeded и т.п.
                                      2. С Redmine все хуже, есть только поддержка ссылок на Issues через соотв. Service у проекта в GitLab
                                        0
                                        А мы вот наоборот, потихоньку, мигрируем с jenkins на gitlab-ci. Основные причины — конфиг CI лежит в вместе с проектом, тестируем в контейнерах, для некоторых проектов свои контейнеры (например ffmpeg собранный с определенными ключами) и баджи с результатом билда в merge request-ах. С jenkins не получилось толком интегрировать gitlab ce (видимо для качественной интеграции нужен gitlab ee).
                                          0

                                          Для jenkins можно попробовать Jenkinsfile

                                        –3
                                        Сделали из Git subversion. Молодцы какие. Хорошо, что я застрял где-то на 7ой версии гитлаба без всяких CI, чатов, треккеров, блокировок файлов, которые не нужны мне, а выкинуть их нельзя.
                                          0
                                          Так можно ж не пользоваться? Я тоже думаю поставить GitLAB, и проинтегрировать с RedMine и Jenkins (а может и MediaWiki)
                                            0

                                            Чата встроенного нет, не переживайте :) Блокировка — это вообще отдельная опция для EE.


                                            СI и issue tracker можно отключить в настройках проекта:


                                            0
                                            Кстати я занимался GitLab и GitLab CI фулл тайм.
                                            Так что надеялся на улучшение качества продукта :) и тут такой подарок!!!
                                              0
                                              Чтобы обойти эту проблему, мы добавили возможность ручной блокировки файлов в GitLab.

                                              Ура, теперь опция «не трогай, я редактирую» доступна и в CVS
                                                +1
                                                Может хочется странного, но хочется иметь «кнопку» для выпуска релиза — merge ветки в develop в master с интерфейса gitlab (с возможностью задать теги, комментарии). Сейчас релизы делаем или через merge request (develop -> master) в gitlab или вручную объединяем ветки и пушим в мастер.
                                                  0

                                                  Gitlab — отличный продукт, однако мне интересно, есть ли в планах следующие фичи?


                                                  • синтаксис поиска как на Github
                                                  • возможность добавлять ssh-ключи для групп (доступ ко всем проектам внутри группы по одному ключу)
                                                  • возможность быстрой смены пользователя
                                                    0
                                                    +100500 за «возможность добавлять ssh-ключи для групп (доступ ко всем проектам внутри группы по одному ключу)». Просто ужас как не хватает, особенно когда проект состоит из множества мелких модулей находящихся в одной группе.
                                                      +1
                                                      А что мешает просто пользователя добавить в группу? Или я что-то непонял вашу задачу.
                                                        +2
                                                        Речь про deploy keys в данном случае. Они только для проектов добавляются и, чтоб тот же npm или composer могли тянуть себе модули при деплое приложения, приходится в каждый модуль-проект добавлять ключи прод и стейдж серверов.
                                                          +1
                                                          Кстати, страничка добавления deploy keys стала дюже не удобная. Раньше это было что-то вроде двух-оконного менеджера, где слева добавленные в проект ключи, а справа те, которые можно добавить. А сейчас все в одном списке-куче, просто добавленные вверху списка. И чтоб добавить еще один ключ, мне несколько раз скроллить приходится и выискивать его.
                                                        0

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


                                                        Насчет поиска и смены пользователя — можете рассказать про ваши сценарии использования?
                                                        Зачем вам нужно менять пользователя вообще? И для чего вам бы пригодился такой поиск?

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

                                                      Самое читаемое