Я создал и теперь поддерживаю плагин IntelliJ, который помогает писать спецификации Spock . С тех пор как я выпустил его, я столкнулся с одной проблемой — поддерживать совместимость с различными версиями IntelliJ. В пятницу кто-то отправил заявку на то, что плагин был снова сломан в предварительной версии IntelliJ. Я решил снова заняться этим вопросом. Недостающий кусок всегда был настройкой непрерывной интеграции. Раздражает (и с каждым выпуском становится все более невозможным) переворачивать IntelliJ Plugin SDK в моей IDE, собирать и запускать тесты для каждой поддерживаемой версии IntelliJ.
Первый подход, который я выбрал, — попытаться решить проблему, скомпилировав и протестировав мой плагин с помощью Gradle. К сожалению, IntelliJ не выпускает свой скомпилированный код в maven central или пакетные вещи таким способом, который поддерживал бы некоторые другие инструменты для их SDK. Наиболее близким к рабочему решению я нашел проект на коде Google, intellij-maven, Использование этого началось многообещающе, но мне не удалось. Проект не включал части IntelliJ, от которых зависел мой плагин. Когда я добавлял каждый кусок, мне приходилось разрабатывать дополнительные сторонние библиотеки, от которых он зависел. Даже когда все скомпилировалось, этот проект строился вокруг локальной проверки исходного кода IntelliJ, а не публикации полного набора jar-файлов, чтобы кто-то мог начать сборку с минимальными затратами (например, на сервере CI). Моя терпимость к использованию инструментов сборки составляет около полутора дней; достигнув этого, я отложил эту идею на некоторое время.
Когда кто-то сообщил, что в 12.1 превью снова что-то сломалось, я решил снова решить проблему с помощью TeamCity . Я догадался (правильно), что он будет изначально понимать файлы проекта IntelliJ. Мне удалось успешно собрать TeamCity для моего плагина на основе нескольких версий IntelliJ SDK. Вот как.
Добавить переменные в файлы проекта
Обычно я никогда не проверяю файлы проекта IDE в vcs. В этом случае необходимо использовать сборки на основе TeamCity IntelliJ. Они поддерживают проверку в файлах проекта . Просто исключите файлы:
.idea/workspace.xml .idea/tasks.xml
Переменная пути для имени JDK является следующей частью необходимой конфигурации. Переменные в файлах проекта определяются, заключая имя в «$». Их локальное значение можно задать в Path Variables, в настройках. Кроме того, после редактирования файла проекта IntelliJ сообщит, что видит новую переменную, для которой требуется значение. Переменная имени JDK позволяет TeamCity конфигурировать разные сборки для разных версий SDK. Этот параметр находится в ./idea/misc.xml.В моем проекте я использовал idea_sdk_name. Эта переменная не обязательна (в TeamCity вы можете переопределить расположение JDK). Без этого, однако, я обнаружил, что конфигурации сбивают с толку, потому что JDK проекта TeamCity назван в честь определенной версии, но значение указывает на другую версию. Кроме того, так как я изменил фактическое значение JDK (вместо переменной пути) в моей IDE, изменение, проверенное в vcs в .idea / misc.xml, сломало бы все сборки (потому что они потребовали бы перенастройки блока настроек JDK). Соответствующий раздел .idea / misc.xml следует.
... <component name="ProjectRootManager" version="2" languageLevel="JDK_1_6" assert-keyword="true" jdk-15="true" project-jdk-name="$idea_sdk_name$" project-jdk-type="IDEA JDK"> <output url="file://$PROJECT_DIR$/out" /> </component> ...
Мой плагин также зависит от двух встроенных плагинов IntelliJ. Их также необходимо настроить в зависимости от версии SDK. Изменение для решения этой проблемы ввело переменную в файл проекта .iml . Я использовал idea_sdk в качестве пути к IntelliJ SDK.
... <orderEntry type="module-library" scope="PROVIDED"> <library name="groovy_plugin"> <CLASSES> <root url="file://$idea_sdk$/plugins/Groovy/lib" /> </CLASSES> <JAVADOC /> <SOURCES /> <jarDirectory url="file://$idea_sdk$/plugins/Groovy/lib" recursive="false" /> </library> </orderEntry> ...
Добавить конфигурацию запуска для тестов
В моем случае меня интересует только регрессивное тестирование, а не развертывание какого-либо артефакта. TeamCity просто нужно скомпилировать и запустить тесты. Я добавил конфигурацию запуска JUnit для выполнения тестов. Ключ здесь, чтобы установить флажок «Поделиться» в конфигурации и проверить в файле XML, который это генерирует.
Настроить TeamCity
Я всегда был пользователем Jenkins, но никто не написал интеграцию IntelliJ, которая мне нужна в этом случае. Бесплатная версия TeamCity позволяет создать 20 конфигураций сборки, чего достаточно для моего плагина.
Я никогда раньше не использовал TeamCity, но у меня не было проблем с его запуском, подключением агента сборки и настройкой проекта. Конфигурации сборки — то, где вещи снова становятся интересными. На третьем шаге конфигурации сборки, «Шаг сборки: проект IntelliJ IDEA», происходит сборка. Вот соответствующие нестандартные параметры конфигурации с объяснением:
Тип бегуна: проект IntelliJ IDEA.
Используйте проект IDEA, поэтому я выбрал TeamCity для этого проекта.
idea_sdk: / Applications / IntelliJ IDEA 11.1 CE.app
Путь к установке IntelliJ. Это путь к другим плагинам IntelliJ, от которых зависит мой источник.
idea_sdk_name IDEA IC-123.169
$ idea_sdk_name $ — Главная страница IDEA
/ Приложения / IntelliJ IDEA 11.1 CE.app
Путь к установке IntelliJ для сборки
$ idea_sdk_name $ — Шаблоны файлов JAR IDEA
lib / *. jar
По умолчанию это значение исключает idea.jar. Для проекта плагина (в зависимости от того, что он делает), idea.jar, вероятно, включает в себя необходимые классы.
$ idea_sdk_name $ — Шаблоны Jar-файлов JDK
jre / lib / *. jar
lib / tools.jar
Мне пришлось добавить tools.jar. Я считаю, что это просто OSX вещь.
Запустите конфигурации для запуска test-app
. Общая конфигурация запуска из предыдущей, настройка для тестирования приложения.
Заворачивать
Я также создал Gist текущего TeamCity project-config.xml .
Поддержание обратной совместимости в будущем будет гораздо менее болезненным. Также, спасибо разработчикам IntelliJ за ответ на мой вопрос, когда я застрял, заставляя TeamCity создать свой исходный код.
Переиздано из моего блога, источник статьи на www.cholick.com/entry/show/270