LINUX.ORG.RU

прокси для github

 


0

1

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

как правильно проксировать гитхаб? Может, есть готовые решения специально для этого, окромя тупо squid'а + git config http.proxy?

Если есть какие-то хорошие решения для конкретных систем сборки (maven, rebar, grunt...), интересны все.

★★★★☆

сейчас принято

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

Если есть какие-то хорошие решения для конкретных систем сборки (maven, rebar, grunt...), интересны все.

git submodule и/или внешняя пакетная система, типа оной вашего дистрибутива

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 1)

Гит, мягко говоря распределенная система, со смещенным в никуда центром.

anonymous
()

каждый «чистый» билд клонируется

ОМГ, это у кого так? Я знаю в aur в archlinux есть криворукие скрипты которые не разделяют фазы download и build, но даже там это фиксить начали.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

Да не, показали педрилам гитхабовским кто тут хозяин, оне и прогнулись. Работает лучше прежнего :)

anonymous
()
Ответ на: комментарий от true_admin

ну а теперь у тебя в билд-файле чото поменялось. Разбираться что поменялось, на что повлияло - себе дороже. Если всё это происходит на continuous integration сервере, автоматически Hudson этого вообще никогда не определит. Проще убить весь кэш и выкачать заново, и знать что у тебя будет точная чистая эталонная сборка. Но это выкачивание занимает время, это раздражает.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от anonymous

Да никто уже разбираться не будет, репутация слита. Раховитян в проекты лучше не брать, в крайних случаях сразу вывозить.

anonymous
()
Ответ на: комментарий от Harald

ну то есть мне надо написать какой-то анализатор, который будет бегать по билд-файлу, по списку клонировать репозитории локально, потом риплейсить в билд-файле урлы репозиториев на локальные и пересобирать? Ну и чекать разницу между удаленной и локальной компией, вовремя делать git pull и git reset --hard HEAD, итп. Отличная идея, но может всё это уже кто-то сделал?

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)

Если есть какие-то хорошие решения для конкретных систем сборки (maven, rebar, grunt...), интересны все.

Для maven, например, есть Nexus. Вместо MCentral прописывают в проектах локальный инстанс Нексуса, и если у него ещё нет пакета в кеше — он его скачивает. Плюс можно перекрывать пакеты из апстрима и добавлять свои.

aidan ★★★★
()
Ответ на: комментарий от stevejobs

ну а теперь у тебя в билд-файле чото поменялось

Это ничего не меняет. У тебя либо есть нужные зависимости, либо нет.

continuous integration

Это тоже ничего не меняет.

Проще убить весь кэш и выкачать заново, и знать что у тебя будет точная чистая эталонная сборка.

Я так и не понял зачем убивать кэш. В чём проблема тупо посмотреть есть ли нужные данные в кэше или нет? Помимо хронической лени программистов.

На случай если остались вопросы подскажу как видел как это сделано в арче. Там в папку типа download делает git clone --depth=1. Потом из неё делается git clone в build. Не самый прямой способ и получается что сырцы склонированы два раза. Но лучше чем каждый раз по сети с десятка реп клонировать.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

В чём проблема тупо посмотреть есть ли нужные данные в кэше или нет?

в чем проблема дать мне ссылку на универсальную софтину, которая это делает достаточно качественно, чтобы собранный ей билд можно не проверяя выкладывать на продакшен?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Я не знаю что ты используешь и не понимаю почему зависимости, например, нельзя один раз поставить в систему.

Если бы это был питон то pip install -r requirements.txt поставит только нужное. Вешаешь эту комманду в какой-нить pre-build hook и дальше собираешь. Ищи похожее для своего ЯП. Хотя, есть вероятность я не понял твоей проблемы.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Потом из неё делается git clone в build. Не самый прямой способ и получается что сырцы склонированы два раза.

git clone в случае клонирования из файловой системы делает хардлинки, если есть возможность.

ilammy ★★★
()
Ответ на: комментарий от ilammy

Это хорошо, но рабочую копию-то не залинкаешь.

Впрочем, и не надо. в Downloads bare repo, а в build тупо делать checkout. Я прав?

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

Да не, показали педрилам гитхабовским кто тут хозяин, оне и прогнулись. Работает лучше прежнего :)

Видел несколько раз в магазине - орет ребенок, клянчит у родителей шоколадку. Родители не реагируют. Дитя с истошными визгами падает и начинает кататься по полу, при этом поглядывая в сторону родителей. У родителей такое видимо уже не впервой - ноль внимания. Тогда с еще более пронзительными криками он начинает биться башкой об пол, и когда из башки уже хлещет кровь, верещит какими-то совсем нечеловеческими воплями, то ли от боли, то ли от обиды. От такого зрелища родители не выдерживают, дают шоколадку. Ребенок тут же замолкает, и с довольным видом победителя, сидя на полу, измазанный в крови и соплях, жрет шоколадку.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.