- 1
- 2
- 3
- 4
- 5
Jenkins Auto-Updater added a comment - Today 00:35
UNSTABLE: Integrated in contoso #223
Create unit test for CN-858; Currently fails-
Куча / Говнокод #13271
+107
Запостил:
someone,
30 Июня 2013
Follow us!
Просто идея использовать Яву для чего-то, где однозначно нужны скрипты - и зачем они это сделали?..
ЗЫ. Компания пользуется билдбоксом. Дженкинс мой персональный, подпольный, т.как пока ИТ что-то сделает...
В яве из коробки есть ЯваСкрипт... Почему бы и нет?
да ладно? где?
А правда, что вы имеете ввиду под "Ява", острова индонезии, сигареты или мотоцикл?
А если коллег много и они не знают жабы, то вообще писать на жабе смысла мало.
Но в целом, конечно, многие задачи неплохо решаются жабой.
Ещё должны быть смарт-карты с поддержкой оной, но по памяти ничего не гуглится. Должно быть что-то типа Java Card.
А что вы скажете на счет приложений под вынь 8 на js ? просто интересно.
Нет, писать ядро на простой и богатой библиотеками жабе, заточенной на многопоточность, и дать юзерам возможность по-быстрому говнявкать скрипты на жабоскрипте.
К примеру, ElasticSearch использует для обновлений индекса ScriptEngine (причём можно выбирать язык, по дефолту MVEL). Redis умеет евалить Lua-скрипты, хоть сам написан на сишке.
> в жабоскрипте не предусмотренно ничего для работы с файловой системой
Биндим в жабе пару объектов в контекст перед вызовом скрипта, профит. Только API нужно будет документировать.
Скрипт делающий то же самое был бы и компактнее, и возможностей больше, и позволил бы пользователю работать со знакомыми программами (которые он может под себя заточил).
Написать часть Женкинса на другом языке (скриптовом)? - до этого была одна проблема с Явой, теперь их стало две.
Но ведь программа, вместо того, чтобы сделать по-человечески (дополнить) делает по-уродски (заменят).
Это типичный стиль корпоративного мЫшления - а т.как подавляющее большинство Явистов мЫшлют по-корпоративному, то и пишут такие уродские программы. Им просто даже в голову не приходит, через какую жопу они это делают.
Если у вас проблемы, попробуйте на досуге поиграться с buildbot.
RAR не нужен *.
* не вброс, он действительно не нужен. Век дискет уже давным-давно прошел.
и да, 7z научился встраиваться в систему, в частности, в контекстное меню?
Вы так говорите, как будто если бы инсталлятор этого не делал, добавить в реестр пару строчек для распаковки архива было бы трудно:
Кстати, а для каких архиваторов есть хелперы типа zipfldr.dll, чтобы не открывать лишних окон при просмотре?
Он это всегда умел... o_O
>открытый 7-zip.
Метью Махони смотрит на эти слова с легким недоумением.
PS А еще есть хацкильный free arc.
Читаются на всех осях* из коробки. Сжатие шустрое и вполне приличное. Зачем что-то еще?
> хороших средств для архивации
Приведите пожалуйста названия средств и то, чем они хороши. И посмотрим, перевесят ли их "преимущества" возможность не заморачиваясь открыть пак с исходниками/бинарниками на любой оси.
Если что-то и было бы полезно - так это совсем не архиваторы, а плагины для генерации deb/rpm/msi и прочих инсталляшек.
* Шиндовз ниже XP осью не считаем.
И в конце концов, я пользуюсь Эмаксом, в нем tar+gzip поддерживается замечательно, а zip - на уровне редактора - не особо. Почему я должен забивать на любимый редактор изза какой-то недоделки в CI сервере?
> Если что-то и было бы полезно - так это совсем не архиваторы, а плагины для генерации deb/rpm/msi и прочих инсталляшек.
CI сервер для этого не предназначен. Просто сбилдить и оповестить всех заинтересованых о результатах. rmp / msi - это уже заботы инструментов сборки, типа SCons / rake и иже с ними.
И вы это считаете проблемами дженкинса? :)
> кучу дискового пространства
В век дискет, 40 гиговых винтов, cd-rw и GPRS'а по 9 рублей за метр я бы полностью с вами согласился... Тогда я жал все в непрерывные RAR архивы, и считал это нормальным... Но у tar.gz, как и у любого непрерывного архива есть недостаток - довольно медленный seek и перечисление файлов. А ведь если вы хотите править файлы внутри архива прямо из редактора это немаловажно?
P.S. Исходники libc в tar.gz весят 23 метра, в zip - 30 (в обоих случаях дефолтовый уровень сжатия). Оно точно того стоит?
Почему я должен платить хоть один американский цент больше за идиотизм другого программиста? Мало ж. диски стоят? - почему автор Женкинса мне их в подарок не пришлет - то ж фигня копеечная?
Кроме непосредственно хранения, это еще время на отсылку их по сети. У нашей компании три больших оффиса и еще несколько по-меньше, в Израиле, Канаде и на Украине. Почему изза идиотизма разработчика Женкинса человек должен ждать в два раза больше, пока билд скачается?
Просто почему делать через жопу то, что уже было сделано нормально?
Не вам судить о том, что я сделал и для кого, уж поверьте, вы ничего об этом не знаете. Опять же, пусть бы даже не было никакого моего личного вклада в развитие чего бы то ни было - какая связь между качеством программы и моим вкладом?
В мире есть очень много примеров посредственных / низкопробных продуктов, которыми пользуются не потому, что они такие хорошие, а потому что привыкли / нет хороших альтернатив. Женкинс - один из них.
Если вы посмотрите сюда: то увидите, что по-сути кроме Трависа, Женкинса и Билдбота ничего и нет. Но Травис заточен специально под Гитхаб...
Собственно, от вас кроме ругани всего кроме Emacs и CL сложно что-то услышать.
CI я сам настраивал не раз, и bulidbot, и Jenkins, и CruiseControl. У всех систем свои недостатки, порой весьма неприятные. Но называть их разработчиков дебилами у меня как-то язык не поворачивается. Тем более, бьюсь об заклад, у вас нет в закромах собственной CI-системы, которую бы все похвалили. Люди делали продукты не для вас, а для себя. И поделились ими с сообществом на добровольных началах. Если вас что-то в них не устраивает - исправляйте, в этом суть опенсорса и его сила. Угодить на всех в гетерогенных средах - очень непростое занятие, поэтому и приходится выбирать метод наименьшего знаменателя.
А уж брызжать слюнями, доказывая иллюзорный идиотизм - совершенно бесполезное и безрезультатное занятие.
Нет, я не знаю ни одного хорошего CI сервера - и это не делает Женкинс лучше, а ынтырпрайз мышление более приемлимым.
Почему я не могу сожалеть о такой плохой ситуации? Сожаление о плохой ситуации - это единственная мотивация для ее изменения.
Идиоты ли авторы Женкинса? - во всем - нет. В реализации конкретной возможности - да.
С чего вы взяли, что я не исправлю и не пошлю патч разработчикам? Наоборот, с какого перепугу я бы стал патчить, если бы меня все устраивало?
Я этого не утверждаю. Наоборот, активно взываю конструктивно решать проблему. Нормальный инженер, находя проблему, не ищет виноватых, тыча в них пальцем, а молча решает её и идёт дальше. А называть разработчиков свободного продукта дебилами - некрасиво, даже если впоследствии кинуть с царского плеча патч.
Кстати, неплохо было бы увидеть ссылку на патч.
Не упоминай Царя всуе.
Я очень обломался изза плохой поддержки Сигвина, и пытаюсь с этим что-то сделать.
Но в процессе работы уже много раз возникало желание просто сделать по-новой. Особенно от того, что от Явы тошнит. Я уже выше говорил о том, что хочу попробовать приспособить elnode для этого - судя по всему, этим все и закончится.
Ваш преемник будет Вас ненавидеть. Ну и в конечном счёте Вы убъёте кучу времени и врядли получите что-то хотя бы отдалённо похожее на нормальный CI-сервер.
tar не умеет упаковывать и нарезать на тома
gzip не умеет работать с несколькими файлами и нарезать на тома
split не умеет упаковывать и работать с несколькими файлами
Тогда как rar умеет это все.
Вывод: unix говно.
P.S. Хотя можно и .rar.rar, где первый rar с отключенным сжатием, а второй сжимает один файл.
скачиваем кучу архивов *.part??.zip
распаковываем каждый отдельно, получаем кучу томов *.r??
распаковываем, получаем один *.zip архив
радуемся, что в нем находится нужное.
Более того, непрерывные архивы имеют смысл только при нормальном размере словаря. У gzip он 64 кбайт, у рара - до 16 мбайт вроде бы, по дефолту 4. У 7z аналогично. Так что прыщебляди соснули, но им не привыкать.
Зачем полностью? Только предыдущие. Последующие файлы на упаковку предыдущих никак не влияют.
P.S. Но в .tar.gz еще и заголовки размазаны по всему архиву и пожаты, поэтому чтобы посмотреть список файлов, придется распаковать весь поток.
А так кто-то умеет? Winrar полностью распаковывает tar только для показа оглавления. В любом случае, из всех знакомых мне архиваторов только rar может располагать файлы в нужном порядке в непрерывных архивах, чтобы readme.txt было в самом начале, причем как минимум с бородатой версии 2.0 под дос. Опенсорсные воры (7zip) это еще не успели прыщеукрасть (15 лет, совсем некуда спешить, как обычно).
Кстати, в непрерывных архивах rar вроде бы может иметь несколько потоков, а gz - только один, т.е. для распаковки одного файла по любому надо будет распаковать все файлы перед ним.
Собсно, 7z - самое лучшее, что было у щвабодных мозолеедов. На их счастье, архиваторы достигли пика развития, и фичи 10-летней давности потихоньку были прыщеукрадены и перекочевали в швабодный продукт. Не пора ли вылезти из подвала?
Если тебе эта фича очень-очень-очень нужна, то добавь сначала очень-очень важные файлы, а затем добавь все остальные. Тар это умел с самого создания. И никаких гуитыкалок или специализированных опций для этого не нужно. Или ты пакуешь каждую версию своей софтины в рар через гуитыкалку, любовно кликая мышкой по README и прочим важным файлам, чтобы они легли первыми?
> Опенсорсные воры (7zip) это еще не успели прыщеукрасть
> прыщеукрадены и перекочевали в швабодный продукт.
Откуда такая ненависть к швабодке и опенсурсу?
Оло ло, а ну ка луркай RarFiles.lst
>Откуда такая ненависть к швабодке и опенсурсу?
Ну посмотри сам - в 2010-х 7zip только-только, наконец-то, подобрался по функционалу к винрару начала 2000х, все остальное у него без шансов сосало. Зип, вон, до сих пор в юникод не умеет. WinHTTTrack - глючная копия Teleport Pro родом из 90х. Про опен офис и мс офис известно. И т.д.
я добавлял в один проект требуемую поддержку .zip архивов - там достаточно взять из поставки полтора файла и написать нужные врапперы, передающиеся в zlib_filefunc_def
Эмакс поддерживает навигацию, поиск, итеративное добавление / удаление из tar+gzip, а к zip он может только применить то, что есть в системе, т.е. в общем случае сжатие / раzжатие.
К примеру, Вижуал Студия не может и того, что может Эмакс при работе с zip файлами.
и да, сэкономить пару метров места на рабочем харде при редактировании кода текущего проекта - да это же киллер-фича, сейчас же деинсталлирую вижуал студию!
Это в сумме или каждый билд?
зачем вы скачиваете интернет?
Если весь набор исходников в tgz весит в районе 300мег, и к-т сжатия будет примерно как я замерял выше для либц (zip на 30% больше, чем tgz), то получим где-то 100 метров разницы на каждом архиве, на 1000 таких архивов как раз получатся те самые 100 гигов.
билд сервер собирает версии
а затем собранным версиям и так положено быть упакованными и они лежат не на билд сервере - а на специальном архивном сервере
но к примеру, 100 гигов версий (даже не дельту в 100 гигов) в архивах наша контора не накопила и за 15 лет - но наверное мы и не крайзис не пишем, текстуры не храним
причем, если уж хранить результат - ну так я бы призадумался о lzma (7z), а не взял старый tar.gz (только потому, что мой редактор умеет работать только с ним)
Да, я знаю об этом...
Но wvxvw выше писал: "Если у меня билды производят текстовые файлы (исходники программы)". Т.е. все-таки там текст.
Но мне не совсем понятно зачем копаться в этом выхлопе и править его эмаксом. Он ведь сгенерен :)
"Если у меня билды производят текстовые файлы (исходники программы)"
Метациклические билды? Ну в жабе бывает автогенерация классов через процессоры аннотаций и всякие hibernate-утилиты, но даже в этом случае желаемой целью обычно являются не их исходники, а джарник с результатами.
Ждем жизненного примера, в котором wvxvw понадобилось поправить выхлоп билдсервера ;)
да уж, с нетерпением.
Ну и какие такие проблемы возникли при реализации этих фишек? Ну кроме лени и ненужности zip'а для авторов эмакса, конечно.
> при работе с zip файлами
Зачем вообще вам понадобилось копаться внутри архивов при помощи IDE? Гвозди тоже отверткой закручиваете?
> zip занимает в два раза больше дискового пространства.
Выше был пример с libc, на котором zip больше на 30%, а не в два раза. Или исходники libc недостаточно текстовые и недостаточно однообразные, чтобы преимущества непрерывного архива начали проявляться?
Например, в эмаксе есть специальный интерактвный поиск-замена по файлам реализованая через интерфейс Диреда, у нее есть специальный режим редактирования, с удобно подобранными коммандами, настроенной подсветкой, интеграцией с другими макросами / пользовательскими функциями добавленными к редактору.
Система множественных выделений, выделений по шаблону, комбинации выделений, теги, закладки и т.д.
Увы, пользователю редактора типа Вижуал Студии это просто не объяснить...
> Зачем вообще вам понадобилось копаться внутри архивов при помощи IDE? Гвозди тоже отверткой закручиваете?
Потому что я так же выполняю административную работу, где копирование, архивация и т.д. - это то, что я делаю, каждый день? Если ваш редактор этого делать вообще не умеет, то не нужно это знание экстраполировать на остальных.
Кстати, основной общий недостаток CI-серверов, который превращает воспроизводимость билдов не более чем в миф - конфиги CI-сервера, как правило, лежат отдельно от проекта (только travis вроде правильнее сделан и цепляет конфиг из дерева исходников).
Это означает, что при смене шагов билда легко можно поломать сборку старых версий.
- на билд сервере есть папка, куда складываются патчи на время когда билд еще не у QA, но уже нельзя коммитить.
- всегда найдется кто-то, кто забудет туда патч положить, или вспомнит об этом слишком поздно, или перепутает папки. Когда людей много, то такие ошибки становятся постоянными.
- билд уходит QA на тестирование, и в первый день, а вернее несколько часов сразу после выясняется, что а) не билдится, б) что-то забыли.
- начинается поиск того, что забыли, в итоге находится, но билдить в это время уже нельзя (т.е. нельзя поднимать версию). И приходится вручную что-то добавлять / изменять.
Каждый раз кто-то получает (не-)строгий выговор, и история в точности повторяется.
А потом, когда коммиты разблокированы, эти патчи из папки заливают обратно, не забывая внести те изменения, которые были проделаны руками... И в первый же день выясняется, что а) не билдится, б) что-то забыли. Потому что тот, кто правил руками в обход билд-системы, что-нибудь да забыл закоммитить...
Столько бесполезного секса, и все ради удовлетворения бюрократического "нельзя поднимать версию билда"...
А ручная правка билда без инкремента номера это же неплохая подстава для QA: они вынуждены доверять Васе-одмину-строительного-сервера в том, что он ничего там не запорол и не напортачил, пока подправлял...
И сам факт правки останется незадокументированным, если уж говорить о бюрократических процедурах...
16² ?
А, вы в 265 опечатались. Ну с кем не бывает...
265
В конечном итоге, в большой системе нельзя это полностью автоматизировать, т.как просто все ошибки нельзя предусмотреть. Вот вам пример нетривиальной баги, с которой я живу уже несколько месяцев:
msysgit (сборка для Виндовс) почему-то на наших виндовсах ведет себя неадекватно - не учитывает сдвиг таймзоны. Т.е. врема коммита отличается от времени в системе на пару часов. Так же странно ведут себя несколько других програм, например, Питон (Виндовская версия), Нода.жс... Но в браузерах, например, время нормальное, в Сигвине, что интересно - время тоже нормальное, и Сигвиновская сборка Гита таки учитывает таймзону.
Предположим теперь, что кто-то закоммитил из Гита с неправильным временем. Версий в этой замечательной системе версий нет. Выяснить "кто же был первым" можно только в процессе личного общения с закоммитившим...
Эм... Время коммита в гите не имеет никакого значения и не может иметь в принципе в распределённой среде, где каждый мог настроить какое угодно время. Последовательность коммитов определяется так, как и должна: отношением родитель - потомок в графе версий.
Закоммитить в "мастер" в принципе невозможно (без --force, разумеется, но за это сажают на кол), пока не смёржишься с ним в локальном репозитории.
Если у каждой локации своя мастер-ветка, а мёрж в "канонический" репозиторий выполняют отдельные люди (что в принципе невозможно в централизованной системе), то тут вопрос, кто коммитил первым, не имеет смысла: они коммитили одновременно.
Да, а как Гит узнает кто жеж был раньше? Он считает время от пуша назад, чтобы выяснить когда коммитили, и кто был первым, если есть противоречие. Но проблема у нас на уровне сети: видя мои коммиты Гит думает, что живет в прошлом даже не потому, что в самом коммите время не правильно указано, а изза рассинхронизации между системным временем и тем, временем, которое использует стевой адаптер.
Я вообще как обнаружил эту интересную особенность - ничего не подозревая, я из прошлого зафигачил коммит поверху коммита сделанного другим человеком. При том, что во время коммита, меня вообще формально даже на работе не было. От так-то.
По sha-1 дайджесту родителя, разумеется. Время бессмысленно, только граф имеет значение.
Почитайте уже, как гит работает. Крайне занимательно.
tell me moar
Я даже пытался разузнать, может быть ситуация не такая уникальная - но похоже что я наблюдаю очередную лажу с датами какого-то народного умельца, только в этот раз пожелавшего остаться неизвестным.
Коммит a47acba был сделан на самом деле за два часа до 4dc3e12
Что в очередной раз доказывает, что гит клал на даты коммитов.
А заставило его принять такое решение тоф факт, что время при общении с моим компьютером было расчитано не правильно.
Подозрение пока на то, что ради прихотей wmwire хоста были сделаны какие-то странные настройки в сети изза которых что-то сломалось. Как результат, все программы написанные на Си почему-то при вызове системных функций связанных со временем получают строго гринвичевское время (wmwire host не может, или не мог когда-то работать ни в какой другой тайм-зоне). Почему-то .NET программы и даже C++ получают нормальное время... Кроме того, тим-фортерес и перфорс (судя по рассказам ИТ) отказывались синхронизироваться, если время на компьютерах в локальной сети отличалось больше чам на сколько-то минут. Оставшиеся ИТ теперь плохо понимают, что тогда было сделано, но факт отстается таким, что у меня на компутере программы на разных языках показывают разное время.
ЗЫ. +1 в логе коммита - это ДСТ.
a47acba - это результат мёржа b89b409 и 4dc3e12, он не мог быть сделан на 2 часа раньше предка, это буллшит.
В 15.42 был ваш коммит, в 15.37 (поправка на косяк со временем) - не ваш. Вы сделали pull, произошёл автомёрж транка с вашим коммитом в 15.51 (по локальному времени, разумеется).
Нет никакой магии, всё как и должно быть: забили на время, используются отношения между версиями.
2. Не ту циферку скопировал, b89b409 - мой коммит, ну как бы можно сказать, что a47acba - тоже мой коммит, т.как получился врезультате мержа того самого моего коммита. Он был на самом деле самым первым в этой серии коммитов. Два следующих за ним коммита должны были его "исправить", в итоге, он "исправил" два последующих коммита. Т.е. врезультате мержа были использованы мои сорцы а не из 3cdc9ec.
А... о... я понял еще в чем проблема. Время то отображается у меня, и оно очевидно вычисляется неправильно на моей системе. Лог на сервере выглядит по-другому :О
Я теперь уже и сам не понимаю почему так. Но это то, что получилось.
С чего это вдруг? Если бы там были конфликты, гит не стал бы ничего коммитить, а предоставил бы вам возможность разбираться, какие изменения должны переписать другие.
То, какой коммит отображается выше в рисунке git log действительно определяется временем коммита. Но на работу самого гита это абсолютно не сказывается. На любом сервере git log будет отображать изоморфный граф ревизий.