Смотрите сами: вот проект, вот история коммитов.
Список контрибьюторов с главной страницы репозитория:
Ссылки на аватарках ведут на странички профилей реальных людей.
Всё на месте. Кроме плашечки "Verified" как здесь:
Знатоки Git и GPG, не торопитесь проматывать ленту: эта статья не про необходимость подписывать свои коммиты. Она про неявные допущения, которые мы делаем, пользуясь "интуитивно-понятными" монстрами GitHub и GitLab и доверяя им контроль доступа к нашим репозиториям.
Git hooks – инструмент, помогающий держать в порядке ваш репозиторий. Можно настроить автоматические правила оформления ваших коммитов.
Все вы наверное знаете про pre-commit — проверку вашего кода перед коммитом. Но ведь не все можно проверить перед коммитом. Некоторые ограничения хочется использоваться глобально на всем Gitlab.
Кто запутался в pre-commit и pre-receive хуках, в этом посте описываются различия между ними в абзаце "What are git hooks?".
Если у вас Gitlab Enterprise Edition, вы можете настроить хуки, которые описаны в посте через WEB интерфейс.
Но что делать, если у вас Gitlab Community (Core) Edition?
В этой статье будут описаны 5 pre-receive хуков, которые выполняются на сервере Gitlab Community (Core) Edition:
Избегайте захламления репозиториев и других действий, которые усложняют управление кодовой базой. Вместо этого используйте лучшие практики, которые помогут упростить работу.
Изучение исходников в репозитории позволяет оценить уровень безопасности приложений. Но если никто не смотрит на код, проблемы будут только расти. К счастью, у GitHub есть свои специалисты по безопасности, которые недавно обнаружили трояна в нескольких репозиториях Git. Его почему-то не заметили сами владельцы этих репозиториев. Хотя мы не можем диктовать другим людям, как управлять своими собственными хранилищами, мы можем учиться на их ошибках. В этой статье мы рассмотрим полезные приёмы работы с репозиториями.
Читать полностью »
В конце мая в нашем инстаграм-аккаунте выступала Наталья Теплухина — Vue.js core team member, GoogleDevExpret и фронтенд-разработчица. Мы анонсировали ее как Senoir, но за неделю до прямого эфира ее повысили и она стала первым Staff Frontend Engineer в Gitlab.
Наташа рассказала, как попасть в команду разработки фреймворка Vue, о его будущем, как попасть в Gitlab, почему джунам не стоит идти на удаленку, и о синдроме красной ручки, которыми страдают русскоязычные команды разработки.
Делимся расшифровкой и записью эфира.Читать полностью »
Наш новый формат — прямые эфиры с успешными разработчиками и айтишниками, на которых вы можете задать вопрос профессионалу и получить ответ из первых рук развивается дальше.
25 мая на ваши вопросы будет отвечать Наталья Теплухина, Vue.js core team member, GoogleDevExpret и Senior Frontend Engineer в GitLab.
Наташа училась на Computer Engineering в техническом вузе, потом много лет работала на скучной должности админа баз данных в информагентстве.
После декрета решила уйти во фронтэнд и за 4 года не только выросла в синьора, но и стала обучать других: она аккредитированный GoogleDevExpret, выступает на конференциях, пишет статьи и гайды.
Сейчас она живет в Киеве и работает в GitLab — это самая большая компания в мире без офисов. В свободное время она работает над фреймворком Vue и выступает на конференциях по фронтенду.
Читать полностью »
Одной из базовых функций языка запросов Prometheus является агрегация временных рядов в режиме реального времени. Также язык запросов Prometheus можно использовать для обнаружения аномалий в данных временных рядов.
Команда Mail.ru Cloud Solutions перевела статью инженера команды инфраструктуры GitLab, где вы найдете примеры кода, которые сможете попробовать на своих системах.
Читать полностью »
В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.
Агрегация по месяцам и тегам репозитория GitLab
GitLab — тот случай, когда активное развитие приносит множество новых и интересных возможностей. Если для потенциальных пользователей это просто один из факторов выбора инструмента, то для действующих — ситуация такова: если вы не обновляли свою инсталляцию GitLab последний месяц, то с большой вероятностью пропустили что-то интересное. В том числе и регулярно выходящие security updates.
О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.Читать полностью »
Я обычно всегда обходился без докера и думал, что докер нужен только для больших проектов в больших компаниях. Но однажды я увидел как работает докер в паре с гитлабом у моего товарища и понял, что мне все таки стоит его изучить. Однако, как обычно это бывает, одной подходящей статьи я не нашел — они были либо слишком сложные, либо не полные, либо подразумевали, что вы все знаете само собой. Мне пришлось долго искать различные источники, соединять все это вместе и в итоге у меня получилось сделать простенький проект и CI/CD для него.
Всю работу можно разделить на три части: на локальной машине, на гитлабе и на сервере.
Итак, для реализации проекта нам понадобится аккаунт gitlab и удаленный сервер с виртуализацией KVM или XEN.
На локальной машине необходимо установить docker.
При этом переменные в настройках групп и проекта можно задать как "файл"или "обычную переменную" и поставить галочки "защищено" и "маскировать".
Начнем с простого наследования и будет постепенно усложняться.
С конечным списком уровней приоритетов можно ознакомиться в конце документа.
Бывает нужно оставить отзыв об исходном коде в репозитории в целом, например при приемке кода на поддержку от других разработчиков или подключаясь к новому проекту.
Процессы ревью в Github и аналогах построены вокруг вносимых изменений, а в нашем случае комментарии нужно дать к состоянию всего кода системы на момент комментирования.
Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
В общем суть метода уже изложена, ниже лишь немного подробностей.
