until-first-error — какой кошмар, думаю одной этой функцией можно было бы закончить статью, сейчас копаюсь в подобном коде, это какой-то ужас, люди, никогда не делайте так, чтобы другим не было мучительно больно, функции с бизнес-логикой должны быть названы с точки зрения бизнес-логики и использовать термины бизнес-логики, не надо абстракции абстракциями погонять, это дорога в мир ужасов разработчика.
Новый Commit — спасибо, что дали возможность отключить данную опцию, попробовал использовать это в течении дня, не зашло от слова совсем + еще и бажное (при попытке закомититься говорит, что не может потому несколько ченджлистов выбрано, но выбран всего один, при этом есть невыбранные ченджлисты из другого проекта). Пожалуйста, не отключайте старый вариант, он уже как родной и работает хорошо и понятно.
Спасибо за предыдущие 4 части, потому что 5-ая часть получилась не столь доходчивой, например по ROLLUP и GROUPING всего пару примеров из первой попавшейся статьи sqlandme.com/2011/07/07/sql-server-tsql-group-by-with-rollup дают больше понимания, чем у вас. Субъективно, данная статья выглядит как «про это надо написать, но сил уже не хватает», не в обиду, а в помощь, чтобы вы больше приводили простых примеров, а не больших портянок с текстами и дальше «Посмотрите, что получилось» при этом таблица с результатом не опубликована, я должен был заранее выполнить все действия, а вдруг я где-то допустил ошибку и мои результаты отличаются от ваших, но я об этом не узнаю, я ведь просто смотрю на то, что у меня получилось и не понимаю, потому что я ожидал другого результата. В общем спасибо за статьи, и очень надеюсь, что примеры заключительной части станут проще и прозрачнее, всего наилучшего.
Отличная таблица в конце статьи, но т.к. выше нее примеров нет, то «снять занавес» не получилось, вот прежняя статья была понятна, мне кажется именно из-за примеров.
На странице www.jetbrains.com/help/upsource/creating-a-project-code-intelligence.html написано «PHP should be installed on the Upsource server.». Мой вопрос: как я могу установить PHP в докер-контейнер, если я использую несколько репозиториев в которых используются разные версии PHP. Забегая вперед Вашего ответа, напрашивается фича: подключение php-fpm по порту. Если я все правильно сказал, будем очень благодарны. Upsource няшка.
Касательно вопроса 2: я понял, Upsource показывает разницу между первым коммитом в текущей ветке и последним коммитом в текущей ветке (а не разницу между последним коммитом в текущей ветке и последним коммитом в master ветке). Надеюсь кому-нибудь это пригодится.
Поднял контейнер upsource:2017.3.2593 и всей командой начали пробовать ревьювить, до этого использовали gitlab и bitbucket. Однако, есть как плюсы, так и минусы. Про плюсы промолчу, а вот про минусы, попробую спросить тут, возможно это не баги, а фичи, просто мы их еще не поняли (я не шучу). Поехали:
1. Когда создаешь ревью ветки, созданное ревью анализируется статичным анализатором, но почему-то для каждого разработчика отдельно, т.е. зашел Вася, у него код еще не проанализирован (нет подсветки, интерактивности) и в правом углу файла крутится прилоадер, к которому если подвести курсор, то видишь надпись: «Code analysis is running, it may take a while», короче надо подождать, подождали, анализ закончился. Заходит в данное ревью Петя, и проходит тот же этап, что и Вася. Таким образом непонятно, зачем анализировать один и тот же код 2 раза + весь код мог бы просто анализироваться фоном, еще до создания ревью.
2. Вася и Петя создали один и тот же файл, но Васин файл попал в master-ветку раньше, а Петин, еще на ревью, однако, Петя создал файл на 5 минут раньше Васи, и очень странно видеть в Петином ревью, что файл создан Петей (еще раз напоминаю, что Васин файл уже в master-ветке). При этом, строки, которые написал Вася, upsource показывает зеленым, словно их написал Петя (еще раз напоминаю, что Васин файл уже в master-ветке, а Петин еще нет).
3. Не хватает возможности переназначать ревью, т.е. был один разработчик, он уволился, его ревью должен добить др. разработчик, хорошо бы его назначить как автором ревью. Или например ревью просмотрено, одобрения не получено, т.к. есть замечания, но нужно оповестить автора, что ревью закончено и он может приступать к правкам (наподобие Assignee в gitlab).
4. Не хватает возможности ставить лейблы на ревью (особенно своих), такая возможность есть в gitlab.
5. Лейблы, которые можно поставить комментарию сделаны оч. неудобно, т.е. сначала нужно оставить комментарий, потом кликнуть на кнопку лейбла, чтобы появился select, потом кликнуть по select-у, и только потом кликнуть по лейблу. Очень хотелось бы иметь следующее flow: пишешь комментарий и вместо кнопки «Add comment» кликаешь по нужному лейблу (которые отображаются ниже поля ввода комментария). Понятно, что все лейблы не поместяться, но самые популяные могли бы выводится сразу, а для остальных, можно сделать и select.
4. Уже говорили, но еще раз, очень не хватает кнопки «Merge review» и функционала вида «merge request» как в gitlab, или «pull request» как в bitbucket.
Заранее спасибо, если поделитесь мыслями (best practics) по флоу, которое ожидали от пользователей upsource, будет просто прекрасно, просто может быть мы чего-то не улавливаем (я серьезно).
Ребята, если вам нужны только unit-тесты, то мой вам совет: не используйте Codeception, т.к. он сильно ограничивает phpunit и как пример: вы просто не сможете воспользоваться phpunit.xml настройками, который описаны в документации к phpunit, еще пример: Codeception использует свой хендлер ошибок, полностью перекрывая PHPUnit_Util_ErrorHandler::handleError, и кроме как хака перекрывающего хендлер обратно, это Вы никак не решите. И таких случаев очень много. В настоящий момент, когда у меня в проекте уже естьCodeception, я не понимаю, зачем Codeception мне нужен для unit-тестов, и найти список плюсов, я увы нигде найти не смог.
Ребята, если вам нужны только unit-тесты, то мой вам совет: не используйте Codeception, т.к. он сильно ограничивает phpunit и как пример: вы просто не сможете воспользоваться phpunit.xml настройками, который описаны в документации к phpunit, еще пример: Codeception использует свой хендлер ошибок, полностью перекрывая PHPUnit_Util_ErrorHandler::handleError, и кроме как хака перекрывающего хендлер обратно, это Вы никак не решите. И таких случаев очень много. В настоящий момент, когда у меня в проекте уже естьCodeception, я не понимаю, зачем Codeception мне нужен для unit-тестов, и найти список плюсов, я увы нигде найти не смог.
Думал тут что-то интересное, а тут какая-то художественная литература
1. Когда создаешь ревью ветки, созданное ревью анализируется статичным анализатором, но почему-то для каждого разработчика отдельно, т.е. зашел Вася, у него код еще не проанализирован (нет подсветки, интерактивности) и в правом углу файла крутится прилоадер, к которому если подвести курсор, то видишь надпись: «Code analysis is running, it may take a while», короче надо подождать, подождали, анализ закончился. Заходит в данное ревью Петя, и проходит тот же этап, что и Вася. Таким образом непонятно, зачем анализировать один и тот же код 2 раза + весь код мог бы просто анализироваться фоном, еще до создания ревью.
2. Вася и Петя создали один и тот же файл, но Васин файл попал в master-ветку раньше, а Петин, еще на ревью, однако, Петя создал файл на 5 минут раньше Васи, и очень странно видеть в Петином ревью, что файл создан Петей (еще раз напоминаю, что Васин файл уже в master-ветке). При этом, строки, которые написал Вася, upsource показывает зеленым, словно их написал Петя (еще раз напоминаю, что Васин файл уже в master-ветке, а Петин еще нет).
3. Не хватает возможности переназначать ревью, т.е. был один разработчик, он уволился, его ревью должен добить др. разработчик, хорошо бы его назначить как автором ревью. Или например ревью просмотрено, одобрения не получено, т.к. есть замечания, но нужно оповестить автора, что ревью закончено и он может приступать к правкам (наподобие Assignee в gitlab).
4. Не хватает возможности ставить лейблы на ревью (особенно своих), такая возможность есть в gitlab.
5. Лейблы, которые можно поставить комментарию сделаны оч. неудобно, т.е. сначала нужно оставить комментарий, потом кликнуть на кнопку лейбла, чтобы появился select, потом кликнуть по select-у, и только потом кликнуть по лейблу. Очень хотелось бы иметь следующее flow: пишешь комментарий и вместо кнопки «Add comment» кликаешь по нужному лейблу (которые отображаются ниже поля ввода комментария). Понятно, что все лейблы не поместяться, но самые популяные могли бы выводится сразу, а для остальных, можно сделать и select.
4. Уже говорили, но еще раз, очень не хватает кнопки «Merge review» и функционала вида «merge request» как в gitlab, или «pull request» как в bitbucket.
Заранее спасибо, если поделитесь мыслями (best practics) по флоу, которое ожидали от пользователей upsource, будет просто прекрасно, просто может быть мы чего-то не улавливаем (я серьезно).
тыщу лет был этот сахарок, кажется еще в пхп 4.3 уже было, пусть синтаксис такой красивый не был, но суть та же: