Don't work with AppCode

[Денис Морозов]

Hi, plugin down't work with AppCode

Plugin version 2.3

I press shortcut 'cmd+shift+x,c' and see log follow:

2016-08-23 13:28:54,894 [ 611768] INFO - BitbucketReferences - Path '/scm/vni/repname' of git remote url 'https://stash.companyname.ru/scm/vni/repname.git' matches Bitbucket Server repository path pattern but no base URI resolved 2016-08-23 13:28:54,894 [ 611768] WARN - BitbucketReferences - Failed to parse scheme of remote URL 'git://maingit.companyname.local/software/repname2.git' 2016-08-23 13:28:54,894 [ 611768] INFO - BitbucketReferences - Discovered Bitbucket repositories: '{}'

[Daniil Penkin]

Добрый день, Денис.

Спасибо за использование Bitbucket Linky и за сообщение о проблемах! Буду рад помочь с их решением :)

Тут две проблемы, и одна мне понятна, — начну с неё.

2016-08-23 13:28:54,894 [ 611768] WARN - BitbucketReferences - Failed to parse scheme of remote URL 'git://maingit.companyname.local/software/repname2.git'

Во втором случае причина проста: схему git:// плагин пока что просто не поддерживает, только http, https, ssh или никакую — в таком случаке она тоже считается как ssh для поддержки URL вида [e-mail]:atlassianlabs/intellij-bitbucket-references-plugin.git. Я исправлю это в ближайшей версии, когда будет свободное время.

2016-08-23 13:28:54,894 [ 611768] INFO - BitbucketReferences - Path '/scm/vni/repname' of git remote url 'https://stash.companyname.ru/scm/vni/repname.git' matches Bitbucket Server repository path pattern but no base URI resolved 

А вот с ошибкой определения в первом случае дело интереснее. Когда плагин предполагает, что репозиторий хостится на Bitbucket Server, он пытается угадать его базовую URL и дёрнуть простой REST-endpoint, чтобы убедиться, что это действительно Bitbucket Server. Иначе плагин мог бы предлагать свои действия даже если репозиторий живёт на каком-то другом хостинге (не на Bitbucket), у которого по случайности совпадает формат URL репозиториев.

Так вот, судя по логу, плагин обнаружил, что URL похож на используемый в Bitbucket Server, но или не смог сделать REST-запрос, или этот запрос вернул ответ, который плагину не понравился.

Как вариант, такая проблема может быть в случае, если Bitbucket Server слушает HTTP/S не на 80 или 443 порту (см. #9). Но я сомневаюсь, что Вы столкнулись с этой проблемой, поскольку вряд ли умышленно поменяли схему в логе на https. Update: я был неправ, https ведь тоже можно слушать на нестандартном порту. Так что, может, Вы удалили порт из URL, когда убирали отсылки к настоящему адресу сервера?

Что именно случилось, логируется на уровне DEBUG (поскольку если какой-то другой хостинг с похожими URL появится, плагин будет периодически пытаться его проверить и, соответственно, засорять лог IDE). Могу ли я попросить Вас включить DEBUG-логирование и воспроизвести проблему? Вот что надо сделать:

• в меню AppCode выбрать Help → Debug Log Settings...

• добавить в открывшемся окне строчку BitbucketReferences

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

• найти в логе свежие записи с тегом BitbucketReferences и выложить сюда в комментарии.

Спасибо!

--

Даниил

[Денис Морозов]

Привет, спасибо за ответ. Лог прикладываю. Возможно проблема из-за самоподписанного сертификата

[Daniil Penkin]

Да, всё верно, проблема в том, что Java не доверяет сертификату HTTPS-соединения. Пожалуй, надо будет добавить описание такого случая в информацию о плагине.

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

Буду очень признателен, если Вы отпишетесь, помогло ли такое решение.

Я не хотел бы отключать проверку HTTPS-сертификатов в коде плагина (технически это возможно), поскольку новые фичи (будут в версии 3) предполагают обмен данными с Bitbucket от имени пользователя, и в этом случае безопасность соединения становится критически важной.

Спасибо.

[Денис Морозов]

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

https://stash.companyname.ru/rest/api/latest/application-properties отвечает:

{"version":"3.11.2","buildNumber":"3011002","buildDate":"1439501189862","displayName":"Stash"}

[Daniil Penkin]

Интересно, зачем тогда нужна эта настройка ¯\_(ツ)_/¯ Постараюсь выяснить на досуге.

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

Большое спасибо за оперативные ответы и помощь в поиске причины ошибок :)

[Денис Морозов]

что ты имеешь в виду под: 'В любом случае, логирование явно могло бы быть лучше'? я прикрепил лог новый под название log2.log или ты хотел бы увидеть вообще весь файл логирования?

еще хочу заметить что я добавил сертификат в кастомный jre который поставляется с AppCode-ом(не знаю, может это окажется важной информацией)

[Daniil Penkin]

Нет, я совсем другое имел в виду :) Я о том, что мне надо бы ещё в паре мест в коде логировать, что именно происходит, чтобы разборы полётов были проще.. В новом логе видно, что исключения нет, но и ответ от сервера плагину не понравился (хотя тот, что ты привел в комментарии, должен был сработать: он подходит под регулярку, которой ответ проверяется).

Насчёт JRE я понял и подумаю, что с этим можно сделать. Идея патчить эту JRE мне не нравится, поскольку при первом же обновлении AppCode изменение потеряется.

[Денис Морозов]

Понятно) Можем поступить проще Скинь мне обмазанный логами плагин, я его у себя запущу, тебе не надо будет париться с настройкой окружения

[Daniil Penkin]

=) Ок, спасибо.

На самом деле, я буду смотреть, как обойти проблему самоподписанных сертификатов, так что окружение всё равно буду поднимать. Да и это, скорее всего, просто: Stash есть в Docker-контейнере, и добавить туда nginx с сертификатом должно быть очень просто. Более того, возможно, nginx уже там есть, я не смотрел.

Так что мне нужно только свободное время. Постараюсь на этой неделе добраться.

[Daniil Penkin]

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

Со Stash 3.11.2 я тоже попробовал — и тоже все заработало, так что этот момент остается непонятным.

Давай попробуем в твоём окружении? Я прикрепил версию плагина с дополнительным логированием результатов проверки. Можешь сначала попробовать запустить с твоим текущим способом решения проблемы сертификата (если ты его не откатил еще)?

Заранее спасибо.

[Денис Морозов]

Установил плагин из атача - заработало

Поставил плагин из репозитория, удалил серт из дре и добавил его в Server Certs. Возможно помогла переустановка плагина. Непонятно

[Daniil Penkin]

Спасибо большое за помощь!

У меня нет идей, почему он не работал тогда.

Значит, осталась проблема с поддержкой схемы git://. Оставляю эту задачу открытой.

[Денис Морозов]

Тебе спасибо

[Daniil Penkin]

Resolved in version 2.4.

[Daniil Penkin]

Removing version: 2.0 (automated comment)