Как сделать свой maven repository на github

Обновлено: 04.07.2024

В Android Studio, если вы хотите включить любую библиотеку в своё приложение, вы просто можете добавить следующую строку с зависимостью в файл build.gradle модуля.

Этого достаточно, чтобы библиотека стала пригодной для использования.

Но как Android Studio извлекает библиотеку? В этой статье подробно описывается, как эта вещь работает, в том числе, как опубликовать свою собственную библиотеку и делиться ею с разработчиками в остальном мире.

Начните с этого простого вопроса, чтобы полностью понять, как это работает. Он просто гуглит для нас библиотеку и загружает в наш проект?

На самом деле всё проще. Android Studio загружает библиотеку с сервера Maven Repository, который мы определили build.gradle. (Apache Maven — это инструмент, разработанный Apache, который предоставляет файловый сервер для распространения библиотек). В основном есть только 2 стандартных сервера, используемых для размещения библиотек для Android, таких как jCenter и Maven Central.

jCenter

Чтобы использовать jCenter в вашем проекте, вы должны определить репозиторий, как показано ниже, в файле build.gradle проекта.

Maven Central

Чтобы использовать Maven Central в своём проекте, вы должны определить репозиторий, как показано ниже, в файле build.gradle проекта.

Обратите внимание, что хотя jCenter и Maven Central являются стандартными репозиториями для библиотек Android, они размещаются в совершенно разных местах, предоставляемых разными провайдерами, и между ними нет ничего общего. То, что доступно в jCenter, не может быть найдено в Maven Central и наоборот.

Помимо этих двух стандартных серверов, мы также можем самостоятельно определить конкретный сервер хранилища Maven, если мы используем библиотеку от некоторых разработчиков, которые хотят размещать свои библиотеки на своем собственном сервере. Fabric.io попадает в этот случай, поскольку размещает свой собственный репозиторий Maven на странице. Если вы хотите использовать любую библиотеку Fabric.io, вам необходимо определить URL репозитория, как показано ниже.

И тогда вы сможете получить доступ к любой библиотеке.

Но какой из способов лучше: загрузить библиотеку на стандартный сервер или разместить наш собственный сервер? Первый. Сделать нашу собственную библиотеку доступной для публики. Другому разработчику не нужно будет ничего определить, кроме строки с зависимостью. Поэтому в этой статье мы сосредоточимся только на jCenter и Maven Central.

Почему существует не только один, а два стандартных репозитория?

Фактически оба из них — репозитории, имеющие одну и ту же обязанность: размещение библиотек Java\Android. Разработчики сами выбирают, куда они хотят загрузить библиотеку.

Сначала Android Studio выбирает Maven Central как репозиторий по умолчанию. Когда вы создадите новый проект на старой версии Android Studio, mavenCentral() будет определен по умолчанию в build.gradle.

Но большая проблема Maven Central заключается в том, что она не подходит для разработчиков. Удивительно сложно туда загрузить библиотеку. Так существует ещё проблема безопасности. По этой причине команда Android Studio решила вместо этого заменить репозиторий по умолчанию на jCenter, поэтому при создании проекта сейчас вы увидите в репозитории по умолчанию именно jcenter().

Есть весомые причины, по которым они решили переключиться на jCenter. Вот некоторые из основных:

  • jCenter предоставляет библиотеку через CDN, что означает, что разработчик может наслаждаться более быстрой загрузкой;
  • jCenter — это самый большой Java-репозиторий на Земле. Таким образом, всё, что доступно в Maven Central, может быть доступно и в jCenter. Другими словами, jCenter является надмножеством Maven Central;
  • загрузить библиотеку на репозиторий очень легко. Не нужно подписывать или делать какие-либо сложные вещи, как на Maven Central;
  • дружественный интерфейс;
  • если вы хотите загрузить свою библиотеку и в Maven Central, вы можете это легко сделать одним кликом на сайте bintray.

Прежде чем мы будем говорить о том, как загрузить библиотеку в jCenter. Мы должны начать с того, как Gradle извлекает библиотеку из репозитория. Когда мы пишем имя зависимости в build.gradle, как именно Gradle загружает эти файлы в ваш проект?

Для начала мы должны знать, из чего состоит библиотека. Она состоит из трёх частей:

В приведённом выше случае GROUP_ID это com.android.support, тогда как ARTIFACT_ID является design, а VERSION — 27.0.0.

Для понимания, GROUP_ID определяет имя группы библиотеки. Возможно, что в одном и том же контексте будет работать более одной библиотеки, работающей с другим проектом. Если библиотека находится в одной группе, она будет иметь один и тот же GROUP_ID. Обычно мы называем его именем пакета разработчика. А затем определяем реальное имя библиотеки в ARTIFACT_ID. Для VERSION определяется только номер версии. Хотя это может быть любой текст, но лучше всего использовать его в формате x.y.z.

И тогда Android Studio загрузит эти файлы и скомпилирует с вашим проектом. Вот и всё, ничего сложного.

Вы должны понимать, что библиотека, вытащенная из репозитория, не имеет ничего особенного, кроме файлов jar или aar, размещённых на сервере репозитория. Это как если бы вы скачали эти файлы самостоятельно, скопировали и скомпилировали с проектом. Но большим преимуществом, которое вы получаете от использования зависимостей, заключается в том. что вам достаточно просто набрать имя зависимости, а Gradle сделает всё остальное.

Как было написано выше, в репозитории размещены файлы двух типов: jar и aar. Что такое jar файл ясно, но что такое aar?

Файл aar разрабатывается поверх файла jar. Это было сделано потому, что некоторые Android-библиотеки должны быть встроены в некоторые Android-файлы, такие как AndroidManifest.xml, Resources, Assets, которые не соответствуют стандарту jar-файла. Поэтому был изобретён aar, чтобы охватит эти вещи. В остальном же это обычный zip-файл, похожий на one-jar, но с другой файловой структурой. jar-файл встраивается в aar с именем classes.jar. Остальное перечислено ниже.

  • /AndroidManifest.xml (обязательно)
  • /classes.jar (обязательно)
  • /res/ (обязательно)
  • /R.txt (обязательно)
  • /assets/ (опционально)
  • /libs/*.jar (опционально)
  • /jni//*.so (опционально)
  • /proguard.txt (опционально)
  • /lint.jar (опционально)

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

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


И поскольку есть довольно много деталей, следующий этап будет разделён на 7 частей, чтобы описывать процесс шаг за шагом.

Часть 1: Создание пакета на Bintray

Прежде всего, вам нужно создать пакет на bintray. Для этого вам нужна учетная запись bintray.

Шаг 2. Как только регистрация будет завершена, зайдите в свой профиль, нажмите Add New Repository, выберите тип Maven и введите название вашего репозитория (например, maven).


Шаг 3. На странице репозитория нажмите Add New Package, чтобы начать создание нового пакета для вашей библиотеки.


Шаг 4. Заполните всю необходимую информацию и нажмите Create package.


Шаг 5. Пакет создан! Теперь на странице репозитория у вас появится созданный пакет, в который вы можете зайти и отредактировать по желанию или просмотреть сведения о нём.

Готово! Теперь у вас есть собственный репозиторий Maven на Bintray, который готов к загрузке библиотеки.

Следующим этапом является Sonatype, провайдер Maven Central.

Часть 2: Создание учетной записи Sonatype для Maven Central

Примечание: вы можете пропустить Части 2 и 3, если у вас нет в планах загружать вашу библиотеку в Maven Central. Однако я предлагаю вам не пропускать, так как есть много разработчиков, которые всё ещё используют этот репозиторий.

Так же, как и jCenter, для использования Maven Central вам необходимо зарегистрировать на сайте провайдера Sonatype.

Что вам нужно знать, так это то, что учетная запись, которую вы должны создать, это учетная запись JIRA Issute Tracker на сайте Sonatype. Для этого перейдите на панель инструментов Sonatype и просто зарегистрируйте учетную запись.

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

Заполните следующую информацию:

  • Проект: Community Support — Maven Central (MVNCENTRAL)
  • Тип задачи: New Project
  • Тема: название вашей библиотеки
  • Group id: поле GROUP_ID вашей библиотеки. Сотрудники Sonatype проверять идентификатор группы на доступность, возможна такая ситуация, когда они могут попросить изменить идентификатор на другой.
  • Project URL: адрес библиотеки, которую вы хотите предоставлять.
  • SCM URL: адрес для контроля версий


Последнее, что нужно сделать — дать bintray ваше имя пользователя на Sonatype OSS. Для этого нужно в настройках вашего профиля перейти на вкладку Accounts.


Нажмите Update и на этом настройка завершена.

Часть 3: Включение автоматической подписи в Bintray

Как упоминалось выше, мы могли загрузить библиотеку в Maven Central через jCenter, но для этого нам нужно сначала подписать эту библиотеку. Bintray предоставляет механизм, чтобы сделать это легко через веб-интерфейс, что позволит автоматически подписывать вашу библиотеку после загрузки.

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

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

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

Если всё было сделано верно, вы увидите информацию, как показано ниже на примере.

Откройте страницу редактирования профиля на Bintray. Зайдите в GPG Signing и заполните поля Public key и Private key содержимым открытого ключа и закрытого ключа соответственно, которые были экспортированы на предыдущем шаге. Нажмите Update чтобы сохранить изменения.

Заключительный шаг — включить автоматическую подпись. Перейдите на страницу репозитория и нажмите Edit. На странице редактирования в самом низу поставьте галочку на GPG Sign uploaded files automatically и нажмите Update.


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

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

Bintray и Maven Central теперь готовы. Перейдём к части в Android Studio.

Часть 4: Подготавливаем проект Android Studio

Во многих случаях нам может потребоваться больше 1 библиотеки для загрузки в репозиторий в одном проекте, и в то же время нам может не понадобиться загружать что-либо. Поэтому лучшей структурой, которую я бы рекомендовал, является разделение каждой части на модуль. В принципе, я предлагаю разделить, по крайней мере, на 2 модуля, один — на модуль приложения для примера использования библиотеки, а второй — на модуль библиотеки, содержащий исходный код, который вы хотите загрузить в репозиторий. Обратите внимание: если вы хотите иметь более 1 библиотеки в своем проекте, создайте ещё один модуль: один модуль на одну библиотеку.


  • app — модуль приложения (apply plugin: ‘com.android.application’), не будет загружен на репозиторий
  • materialfilepicker — модуль библиотеки (apply plugin ‘com.android.library’), будет загружен на репозиторий

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

Далее следует применить плагин bintray к вашему проекту. Для этого нам нужно изменить файл build.gradle проекта, добавив зависимость.

Затем вы определим имя пользователя и ключ API, используемые для аутентификации в Bintray, изменив local.properties. Причина, по которой нам нужно помещать эти данные именно в этот файл, заключается в том, что этими данными не нужно делиться ни с кем, а файл local.properties по умолчанию внесён в .gitignore. Поэтому эти конфиденциальные данные не будут загружены в git непреднамеренно.

Вот две строки, которые нужно добавить:

Поместите свои имя пользователя и ключ API, который вы можете найти в настройках профиля на Bintray в поле API Key.

Последний шаг, который нужно изменить — это файл build.gradle модуля. Откройте его и поместите эти строки сразу после apply plugin ‘com.andorid.library’.

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

Готово! Теперь ваш проект настроен и готов к загрузке на bintray.

Часть 5: Загружаем библиотеку на bintray

Настало время загрузить вашу библиотеку в свой репозиторий на bitntray. Для этого перейдите на вкладку Terminal в Android Studio.

Первый шаг — проверить правильность кода и собрать файлы библиотеки (aar, pom и т.д.). Введите следующую команду для этого.

Если всё хорошо, вы увидите что-то вроде:

Мы уже на полпути. Следующий шаг — загрузить собранные файлы в bintray с помощью следующей команды.

Проверьте свой пакет на сайте bintray. Вы увидите изменения в области Versions.


Нажмите на вкладку Files, и вы увидите загруженные файлы вашей библиотеки.


Поздравляем, ваша библиотека теперь и сети и готова для использования всеми людьми!

Однако не радуйтесь раньше времени. Библиотека всё ещё находится на вашем собственном репозитории Maven, но не в jCenter. Если кто-то захочет использовать вашу библиотеку, они должны сначала определить URL вашего репозитория, как показано ниже.

Вы можете найти URL вашего репозитория в веб-интерфейсе bintray. Вы можете пройти по этому URL и увидеть структуру изнутри.

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

Часть 6: Синхронизируем наш репозиторий с jCenter

Сделать это достаточно легко. Просто зайдите на страницу своего репозитория и нажмите Add to JCenter. В появившемся окне ничего не заполняем и просто жмём Send.


С этого момента любой разработчик, использующий репозиторий jcenter(), сможет использовать вашу библиотеку, добавив зависимость.

Обратите внимание, что синхронизация с jCenter — это одноразовое действие. С этого момента, если вы производите какие-либо изменения в своём пакете, эти изменения также добавятся в jCenter.

И будьте осторожны. Если вы решите удалить пакет, файлы библиотеки, размещённые в jCenter, в этом случае не будут удалены. Они останутся там, как файлы зомби, которые больше никто не сможет удалить. Поэтому если вы хотите удалить пакет, сначала удалить каждую версию из веб-интерфейса.

Часть 7: Пересылаем библиотеку в Maven Central

Не все разработчики Android используют jCenter. Есть ещё множество разработчиков, пользующихся mavenCentral(), поэтому давайте загрузим библиотеку в Maven Central. Чтобы переслать библиотеку из jCenter в Maven Central, вам нужно достичь двух целей:

  1. Пакет bintray должен быть связан с jCenter
  2. Репозиторий на Maven Central должен быть одобрен

Способ пересылки пакета в Maven Central невероятно прост. Просто нажмите на странице пакета на Maven Central.

Введите имя пользователя и пароль от аккаунта Sonatype и нажмите Sync.

Когда всё будет сделано, вы можете найти свои файлы в Maven Central Repository в каталоге, соответствующем идентификатору группы.

Поздравляю! Это всё. Хотя для этого потребовалось довольно много шагов, но сами шаги просты. И большинство из них — одноразовые действия.


Мне частенько приходится строить пайплайн для сборки проектов на Java. Иногда это опенсорс, иногда нет. Недавно я решил попробовать перенести часть своих репозиториев с Travis-CI и TeamCity на GitHub Actions, и вот что из этого получилось.

Что будем автоматизировать

Для начала нам нужен проект, который мы будем автоматизировать, давайте сделаем небольшое приложение на Spring boot / Java 11 / Maven. В рамках этой статьи логика приложения нас интересовать не будет совсем, нам важна инфраструктура вокруг приложения, так что нам хватит простенького REST API контроллера.

JIRA и планирование

Стоит сказать, что мы обычно используем JIRA в качестве трекера задач, так что давайте заведем отдельную борду под этот проект и накидаем туда первые задачи:


Чуть позже мы еще вернемся к тому, что интересного могут дать в связке JIRA и GitHub.

Автоматизируем сборку проекта

Наш тестовый проект собирается через maven, так что сборка его довольно простая, все, что нам нужно, это mvn clean package.

on — это описание события, по которому будет запускаться наш скрипт.

on: pull_request / push — говорит о том, что этот workflow нужно запускать при каждом пуше в мастер и создании пулл-реквестов.

Дальше идет описание заданий (jobs) и шаги выполнения (steps) для каждой задачи.

runs-on — тут мы можем выбрать целевую ОС, на удивление можно выбрать даже Mac OS, но на приватных репозиториях это довольно дорогое удовольствие (в сравнении с linux).

uses позволяет переиспользовать другие экшены, так например при помощи экшена actions/setup-java мы устанавливаем окружение для Java 11.

При помощи with мы можем указать параметры с которыми запускаем действие, по сути это аргументы, которые будут передаваться в экшен.

Остается только запустить мавеном сборку проекта: run: mvn -B clean package флаг -B говорит о том, что нам нужен non-interactive mode, чтобы мавен вдруг не захотел что-то у нас спросить


Отлично! Теперь при каждом коммите в мастер, запускается сборка проекта.

Автоматизируем запуск тестов

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

Делаем запуск тестов при создании пулл-реквеста и merge в мастер, а заодно добавим построение отчета о code-coverage.

Для покрытия тестов я использую codecov в связке с jacoco плагином. У codecov есть свой экшен, но ему для работы с нашим pull-request-ом нужен токен:

$> — такую конструкцию мы будем встречать еще не один раз, secrets это механизм хранения секретов в гитхабе, мы можем там прописать пароли/токены/хосты/url-ы и прочие данные, которыми не стоит светить в кодовой базе репозитория.

Добавить переменную в secrets, можно в настройках репозитория на GitHub:


Получить токен можно на codecov.io после авторизации через GitHub, для добавления public проекта нужно просто пройти по ссылке вида: GitHub user name/[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.


Добавляем jacoco плагин в POM-файл:

Теперь в каждый наш пулл-реквест будет заходить codecov бот и добавлять график изменения покрытия:


Добавим статический анализатор

В большинстве своих oпенсорс-проектов я использую sonar cloud для статического анализа кода, его довольно легко подключить к travis-ci. Так что это логичный шаг при миграции на GitHub Actions, сделать тоже самое. Маркет экшенов — клевая штука, но в этот раз он немного подвел, потому что я по привычке нашел нужный экшен и прописал его в workflow. А оказалось, что sonar не поддерживает работу через действие для анализа проектов на maven или gradle. Об этом конечно написано в документации, но кто же ее читает?!

Через действие нельзя, поэтому будем делать через mvn плагин:

Dsonar.projectKey — название проекта в сонаре, посмотреть можно в настройках проекта.

Делаем пулл-реквест и ждем, когда sonarcloud[bot] придет в комментарии:


Release management

Билд настроили, тесты прогнали, можно и релиз сделать. Давайте посмотрим, как GitHub Actions помогает существенно упростить release managеment.

Как нам может помочь GitHub actions? Есть отличный экшен — release drafter, он позволяет задать шаблон файла release notes, чтобы настроить категории пулл-реквестов и автоматически группировать их в release notes файле:


Пример шаблона для настройки отчета(.github/release-drafter.yml):

Добавляем скрипт для генерации черновика релиза (.github/workflows/release-draft.yml):

Все пулл-реквесты с этого момента будут собираться в release notes автоматически — magic!

Теперь любой pull-request нужно пометить одним из тэгов: type:fix, type:features, type:documentation, type:tests, type:config.


Авто-аннотирование пулл-реквестов

Раз уж мы коснулись такой темы как эффективная работа с пулл-реквестами, то стоит сказать еще о таком экшене, как labeler, он проставляет метки в PR на основании того, какие файлы были изменены. Например, мы можем пометить как [build] любой пул-реквест в котором есть изменения в каталоге .github/workflow .

Подключить его довольно просто:

Еще нам понадобится файл с описанием соответствия каталогов проекта с тематиками пулл-реквестов:

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

Пора деплоить


Я попробовал несколько вариантов деплоя через GitHub Actions (через ssh, через scp, и при помощи docker-hub), и могу сказать, что, скорее всего, вы найдете способ залить бинарку на сервер, каким бы извращенным не был ваш pipeline.

Мне понравился вариант держать всю инфраструктуру в одном месте, поэтому рассмотрим, как сделать деплой в GitHub Packages (это репозиторий для бинарного контента, npm, jar, docker).

Cкприпт сборки docker образа и публикации его в GitHub Packages:

Для начала нам надо собрать JAR-файл нашего приложения, после чего мы вычисляем путь к GitHub docker registry и название нашего образа. Тут есть несколько хитростей, с которыми мы еще не сталкивались:

Далее нам нужно собрать докер-образ:

docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"

Авторизоваться в registry:

И опубликовать образ в GitHub Packages Repository:

docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"

Для того чтобы указать версию образа, мы используем первые цифры из SHA-хэша коммита — GITHUB_SHA тут тоже есть нюансы, если вы будете делать такие сборки не только при merge в master, а еще и по событию создания пулл-реквеста, то SHA может не совпадать с хэшем, который мы видим в истории гита, потому что действие actions/checkout делает свой уникальный хэш, чтобы избежать взаимных блокировок действий в PR.



Там же можно посмотреть список версий докер-образа.

Остается только настроить наш сервер на работу с этим registry и запустить перезапуск сервиса. О том как это сделать через systemd, я, пожалуй, расскажу в другой раз.

Мониторинг

Давайте посмотрим несложный вариант, как делать health check нашего приложения при помощи GitHub Actions. В нашем бутовом приложении есть actuator, так что API для проверки его состояния даже и писать не надо, для ленивых уже все сделали. Нужно только дернуть хост: SERVER-URL:PORT/actuator/health

Все, что нам нужно — написать таск проверки сервера по крону, ну а если вдруг он нам не ответит, то будем слать уведомление в телеграм.

Для начала разберемся, как запустить workflow по крону:

Проверку статуса сервера сделаем руками через curl:


Не забудьте прописать в секретах на гитхабе: URL для сервера и токены для телеграм бота.

Бонус трек — JIRA для ленивых

Я обещал что мы вернемся к JIRA, и мы вернулись. Сотни раз наблюдал на стендапах ситуацию, когда разработчики сделали фичу, слили ветку, но забыли перетянуть задачу в JIRA. Конечно, если бы все это делалось в одном месте, то было бы проще, но фактически мы пишем код в IDE, сливаем ветки в bitbucket или GitHub, а задачи потом таскаем в Jira, для этого надо открывать новые окна, иногда логиниться еще раз и т.д. Когда ты прекрасно помнишь, что надо делать дальше, то открывать борду лишний раз нет смысла. В итоге, утром на стендапе надо тратить время на актуализацию доски задач.

GitHub поможет нам и в этом рутинном занятии, для начала мы можем перетягивать задачи автоматом, в колонку code_review, когда закинули пулл-реквест. Все, что нужно — это придерживаться соглашения в наименовании веток:

[имя проекта]-[номер таска]-название

Интеграция с JIRA работает через экшены от Atlassian, они не идеальны, надо сказать, что некоторые из них у меня вообще не заработали. Но мы обсудим только те, что точно работают и активно используются.

Для начала нужно пройти авторизацию в JIRA при помощи действия: atlassian/gajira-login

Вычленяем идентификатор задачи из названия ветки:

Если поискать в GitHub marketplace, то можно найти действие для этой задачи, но мне пришлось написать тоже самое через grep по названию ветки, потому что это действие от Atlassian ни в какую не захотело работать на моем проекте, разбираться, что же там не так — дольше, чем сделать руками тоже самое.

Для этого есть специальное действие на GitHub, все, что ему нужно — это идентификатор задачи, полученный на предыдущем шаге и авторизация в JIRA, которую мы делали выше.

Таким же образом можно перетягивать задачи при merge в мастер, и других событиях из GitHub workflow. В общем, все зависит от вашей фантазии и желания автоматизировать рутинные процессы.

Выводы

Если посмотреть на классическую диаграмму DEVOPS, то мы покрыли все этапы, разве что кроме operate, думаю, если постараться, то можно найти какой-нибудь экшен в маркете для интеграции с help-desk системой, так что будем считать что pipeline получился основательный и на основании его использования можно сделать выводы.


  • Marketplace с готовыми действиями на все случаи жизни, это очень круто. В большинстве из них еще и исходники можно посмотреть, чтобы понять как решить похожую задачу либо запостить feature request автору прямо в гитхаб репозитории.
  • Выбор целевой платформы для сборки: Linux, mac os, windows довольно интересная фича.
  • Github Packages отличная вещь, держать всю инфраструктуру в одном месте удобно, не надо серфить по разным окошкам, все в радиусе одного-двух кликов мыши и прекрасно интегрировано с GitHub Actions. Поддержка docker registry в бесплатной версии — это тоже хорошее преимущество.
  • GitHub прячет секреты в логах сборки, поэтому пользоваться им для хранения паролей и токенов не так уж и страшно. За все время экспериментов мне не удалось ни разу увидеть секрет в чистом виде в консоли.
  • Бесплатен для Open Source проектов

На следующей неделе я буду выступать с докладом на конференции Heisenbug 2020 Piter. Расскажу не только, как избежать ошибок при подготовке тестовых данных, но и поделюсь своими секретами работы с наборами данных в Java-приложениях!

При работе с Maven под репозиторием мы понимаем директорию, где хранятся все JAR, библиотеки, плагины и любые артефакты, которыми Maven может воспользоваться.

Существует три типа репозиториев Maven:

Локальные репозитории

Локальный репозиторий – это директория, которая хранится на нашем компьютере. Она создаётся в момент первого выполнения любой команды Maven.

Локальный репозиторий Maven хранит все зависимости проекта (библиотеки, плагины и т.д.). Когда мы выполняем сборку проекта с помощью Maven, то все зависимости (их JAR-файлы) автоматически загружаются в локальный репозиторий. Это помогает нам избежать использование ссылок на удалённый репозиторий при каждой сборке проекта.

По умолчанию, локальный репозиторий создаётся Maven в директории %USER_HOME%. Для того, чтобы изменить директорию нам необходимо указать её в файле settings.xml, который находится в папке %M2_HOME%\conf.

Когда мы выполним команду run Maven, то все зависимости будут автоматически загружены в локальный репозиторий.

Центральный репозиторий

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

Удалённый репозиторий

Для того, чтобы предотвратить подобную ситуацию, в Maven предусмотрен механизм Удалённого репозитория, который является репозиторием, который определяется самим разработчиком. Там могут храниться все необходимые зависимости.

Для того, чтобы настроить удалённый репозиторий, необходимо внести следующие изменения в файл pom.xml.

Порядок поиска зависимостей Maven

Когда мы выполняем сборку проекта в Maven, автоматически начинается поиск необходимых зависимостей в следующем порядке:

Для начала запустите IDEA. Кликните File ➣ New ➣ Project From Version Control…


IDEA импорт проекта из GitHub


IDEA git project URL

URL любого проекта GitHub можно легко получить на самой странице с проектом, для этого нужно кликнуть на кнопку Code, а затем скопировать URL, как показано на изображении ниже:


URL проекта в GitHub

Именно этот URL и использовался как URL репозитория Git на прошлом изображении.

Разрабатывая библиотеку, рано или поздно приходит момент, когда нужно поделиться ею с другими. Нет, я сейчас говорю не про выкладывание исходников на GitHub, а про публикацию библиотеки в репозиторий Maven Central. Тем более, что выкладывать исходники там не обязательно, допускаются и проекты с закрытым исходным кодом.
Процесс публикации не слишком простой, поэтому без мануала не обойтись. Есть статья на Хабре, но в ней описана публикация Java-библиотеки при помощи Maven, а в моём случае библиотека для Android и используется Gradle, так что процесс значительно отличается.

Остальные поля проблем вызвать не должны - указываем ссылку на репозиторий, где размещён проект.

5.jpg

После создания тикета на почту придёт уведомление.

1.3. Остаётся только подождать, когда рассмотрят вашу заявку. Как я понял, шансы на быстрый ответ увеличиваются ближе к ночи (очевидно, когда у них в часовом поясе рабочий день).
Сотрудник просмотрит всё детально и оставит комментарий с дальнейшими указаниями и просьбой отписаться, когда всё будет сделано.


Шаг 2. Настройка Gradle для публикации
В Maven репозиторий отправляются скомпилированные классы (или aar-архив с классами и ресурсами, если это Android библиотека), исходники (если требуется) и JavaDocs. Всё это дело надо подписать, а чтобы не делать это вручную, необходимо настроить Gradle.

Читайте также: