Git *

DevSecOps помогает командам обнаруживать и устранять неисправности и уязвимости на ранних стадиях разработки ПО. В GitLab 13.3 создавать безопасное программное обеспечение стало проще благодаря тестированию фаззингом, интегрированному в ваш рабочий процесс разработки. Фаззинг-тестирование, направленное на полное покрытие кода, вместе с запуском DAST (динамического тестирования безопасности приложений) по требованию помогут обнаруживать реальные уязвимости программного обеспечения быстрее и эффективнее. Кроме того, с новой матрицей сборки для CI/CD станет проще выпускать релизы более часто. Наконец, панель состояния подов повысит эффективность работы специалистов по эксплуатации за счёт сокращения переключений контекста: все данные о состоянии подов Kubernetes теперь находятся в одной панели. Мы надеемся, что вам понравятся основные фичи релиза, а также ещё 69 новых фич, включённых в этот релиз.

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

В большинстве случаев требуется типовая задача: "сгенерировать YAML и положить его в Kubernetes". Собственно, с чем Argo CD замечательно и справляется.

Argo CD позволяет подключить Git-репозиторий и синкать его состояние в Kubernetes. По умолчанию есть поддержка нескольких видов приложений: Kustomize, Helm чарты, Ksonnet, голый Jsonnet или просто директории с YAML/JSON манифестами.

Большинству пользователей этого набора будет достаточно, но не всем. Для того чтобы удовлетворить потребности всех и каждого в Argo CD имеется возможность использовать custom tooling.

В первую очередь интересует возможность добавления поддержки qbec и git-crypt, которые с полна были рассмотренны в предыдущей статье.

Disclaimer: Эта история произошла несколько лет назад. Но кажется, что она и до сих пор не утратила актуальности.

… Мы разрабатывали Gardenscapes. В нём всё ещё оставались следы старого Gardenscapes под Windows. Он даже был не Match-3, а Hidden Object. И никто даже и представить не мог высот, которых достигнет игра.

И вот в один прекрасный день…

Смотрите сами: вот проект, вот история коммитов.

Список контрибьюторов с главной страницы репозитория:

Ссылки на аватарках ведут на странички профилей реальных людей.

Всё на месте. Кроме плашечки "Verified" как здесь:

---

Знатоки Git и GPG, не торопитесь проматывать ленту: эта статья не про необходимость подписывать свои коммиты. Она про неявные допущения, которые мы делаем, пользуясь "интуитивно-понятными" монстрами GitHub и GitLab и доверяя им контроль доступа к нашим репозиториям.

Каждой предоставляемой услугой Selectel можно управлять в личном кабинете — панели управления. Многими нашими продуктами также возможно управлять через запросы к API. Инструкции по работе с продуктами и документация API доступны в едином справочном центре.

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

Далее расскажем о том, как мы изменили подход к подготовке документации и обновили внешний вид базы знаний.

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

Доброго времени суток, читатель!

22 апреля в GitLab выпустили релиз 12.10 и сообщили о том, что теперь CI-процесс может авторизовываться в Hashicorp's Vault через JSON Web Token (JWT), и для авторизации нет необходимости хранить токен для доступа к нужным policy в переменных окружения (или где-либо ещё).

Данная фича показалась нам полезной, поэтому предлагаем перевод соотвествующего туториала из официальной документации GitLab:

*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".

В комментариях к статье 15 базовых советов по Git для эффективной работы каждый день развернулась дискуссия на тему эффективности использования тех или иных команд и опций. Надо признать, что git предоставляет столько различного функционала, что во-первых, за всем становится невозможно уследить, а во-вторых, его можно совершенно по-разному вписывать в рабочий процесс.

Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.

Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).

Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.

Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.

Релиз GitLab 13.1 уже доступен! Улучшения нового релиза включают расширенное управление уведомлениями и инструменты, которые помогут вам контролировать и улучшать качество кода, а также другие способы поддержания безопасности и соответствия вашего кода требованиям.

Привет, хабр! Продолжаю делиться полезными подборками. Я уже публиковал посты с Github репозиторими (Часть 1 и Часть 2), а также подборку из 10 книг для разработчиков. Решил, не останавливаться:) Кому интересно — добро пожаловать под кат.

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:

• block_confidentials.sh — Блокирование отправки приватных ключей и AWS токенов
• block_file_extensions.sh — Блокирование отправки архивов (Regex настраивается)
• check-large-files.sh — Блокирование отправки больших файлов (Размер настраивается)
• reject-not-allowlist-email.sh — Блокирование коммитов с email не из allow списка (Список email доменов настраивается)
• require-issue.sh — Блокирование коммитов без issue в названии (Список issue настраивается)

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



Изучение исходников в репозитории позволяет оценить уровень безопасности приложений. Но если никто не смотрит на код, проблемы будут только расти. К счастью, у GitHub есть свои специалисты по безопасности, которые недавно обнаружили трояна в нескольких репозиториях Git. Его почему-то не заметили сами владельцы этих репозиториев. Хотя мы не можем диктовать другим людям, как управлять своими собственными хранилищами, мы можем учиться на их ошибках. В этой статье мы рассмотрим полезные приёмы работы с репозиториями.

«Мы вовсе не собираемся разрушать ваш старый мир. Мы собираемся построить новый. Вот вы – жестоки: вы не представляете себе строительство нового без разрушения старого. А мы представляем себе это очень хорошо. Мы даже поможем вашему поколению создать этот ваш рай, выпивайте и закусывайте на здоровье. Строить, господин Банев, только строить. Ничего не разрушать, только строить.»
— А и Б Стругацкие, «Гадкие лебеди»

Этот пост я задумываю как рискованный эксперимент. Я хочу выяснить, могут ли ИТишники самоорганизоваться для создания открытого, свободного (от слова freedom, а не free beer), чистого, высококлассного «кода», используя привычные им инструменты (Git, fork, TDD, agile, stackoverflow, абстракции, юнит-тесты и прочее). Только этот «код» — это текст, который мог бы являться конституцией в альтернативной реальности (или фантастического рассказа), очень близкой к нашей. Если тебе не нравится чужой код — напиши свой.

Являются ли программисты теми, кто пишет сценарий будущего или просто теми, кто пишет патчи за деньги?

Заодно попробуем составить базу знаний лучших решений, какие были за историю конституций всех времен и народов, методов написаний и улучшений, а так же dark pattern'ы. Например, довольно поучительный кейс Исландии, как они писали-писали вики-конституцию, но так и не написали. Не помогли ни кастрюли, ни батя Бьорк, ни то, что их всего 300 000 человек.

(Надеюсь, что читатели Хабра смогут отнестись к моей идее конструктивно и не превратят в балаган. Если превратят — то скрою статью и завершу «эксперимент».)

Тема живая, продолжение в канале @GaaS

Одной из самых нужных функций, которой нет в бесплатной версии GitLab, является возможность голосования против обнуления репозитория контролировать Merge request (MR), используя обязательный code review.

Сделаем минимальный функционал сами — запретим Merge, пока несколько разработчиков не поставят «палец вверх» на MR.

Что изменилось со времени 12.0

Прежде чем приступить к описанию нового мажорного релиза 13.0, мы хотели бы уделить внимание пройденному пути. Мы столького достигли с момента выхода версии 12.0! Недавно в блоге вышел специальный пост, в котором мы сделали обзор релизов GitLab с 12.0 по 12.10. Три наших фаворита из этой серии релизов это управление требованиями, сетевая безопасность контейнеров и конвейеры (в русской локализации GitLab «сборочные линии») родитель-ребенок.

16 июня приглашаем вас на бесплатную онлайн-лекцию о быстрой автоматизации и развертывании ПО для хакатонов при помощи Ansible.

Лектор: старший разработчик платформы бизнес-сервисов «МегаФона» Антон Гладышев.

Зарегистрироваться

Добрый день. Команда, занимающаяся переводом продукта GitLab на добровольных началах, хочет обратиться к сообществу разработчиков, тестировщиков, менеджеров и других специалистов, работающих с этим продуктом, а также ко всем неравнодушным. Следует отметить, что это не новая инициатива, русский язык существует в GitLab достаточно давно. Однако в последнее время процент перевода увеличивается и нам бы хотелось сделать упор на качестве.

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

Доброго дня!

Меня зовут Соболев Андрей и сегодня я вам расскажу как мы приготовили .pre-commit hook на нашем проекте.

Вступление

Для начала пару слов, о том что такое в целом хуки (hooks) и для чего они могут быть нужны. Git «из коробки» предоставляет инструмент, который умеет запускать ваши скрипты при наступлении какого-либо события (к примеру пуш на сервер и т.п.)

.pre-commit это удобная надстройка над дефолтным git pre-commit hook, которая запускает скрипты описанные в .pre-commit-config.yaml перед созданием коммита. В теории звучит просто, перейдем к практике.

Tree of Dragons II by surrealistguitarist

Для тех, кто каждый день использует Git, но чувствует себя неуверенно, команда Mail.ru Cloud Solutions перевела статью фронтенд-разработчика Шейна Хадсона. Здесь вы найдете несколько трюков и советов, которые могут немного облегчить работу с Git, а также подборку статей и мануалов более продвинутого уровня.