Автоматические ночные сборки и релизы GitHub?

Travis CI используется для сборки и прогонки тестов, и в этом плане он полностью устраивает.
Вот мне бы как раз это место с хранением релизов (желательно чтобы и сборка была там же). Не хочется городить что-то для этой самой сборки и хранения релизов, но судя по отсутствию решений либо городить свое, либо создавать такой сервис самому.

"Место хранения" и "место сборки" - совершенно разные вещи, не имеющие ничего общего. "Место сборки" - это виртуальные машины, CI, какие-то мощные сборочные серверы. Это как раз и есть Travis - он же собирает, чтобы прогонять тесты - почему бы ему не генерировать артифакты? "Место хранения" - это CDN, раздающий файлы. Если хочется такой CDN - один из самых простых выборов - SourceForge. Не нравится SF - выберите любое из поддерживаемых файлохранилищ в Travis - docs.travis-ci.com/user/deployment - или напишите свой скрипт из одной строчки, который загрузит в то файлохранилище, которое вам нравится.

GreyCat: Если посмотреть - там домен .com, я бы не хотел ключи доступа в .travis.yml писать

У Travis есть шифрованные переменные - см. stackoverflow.com/questions/9338428/using-secret-a... - если совсем коротко - то в .travis.yml пишется некая base64-белиберда, ключ для расшифровки которой передается Travis'у отдельно и хранится у него. После чего единственный, кто может расшифровать и прочитать содержимое таких переменных - это сам Travis.

Альтернативно - если задача просто не светить ключами в .travis.yml - то можно задать их переменными среды в веб-интерфейсе Travis'а - docs.travis-ci.com/user/environment-variables/#Usi...

GreyCat: А вот про это забыл, спасибо что напомнили. Теперь нужно определиться куда складывать сборки. SourceForge как-то не сильно удобно.

SourceForge наоборот себя сейчас сильно хвалит, как суперудобное место для file upload для беглецов с GitHub downloads - sourceforge.net/blog/github-projects-downloads-are... - весь upload одной командой; сейчас есть еще GitHub release API - https://developer.github.com/v3/repos/releases/#up... - но он как раз более сложный и геморройный: там надо создавать сам объект-релиз, назначать ему атрибуты, а потом аттачить бинарник; как альтернатива - всегда есть S3 (для не очень больших объемов Amazon его раздает во free tier на первый год), есть облака OpenShift и ownCloud (и те, и другие в не очень больших объемах раздают кучи провайдеров); в общем, вопрос в объемах и целях.

GreyCat: ownCloud я и сам использую. Цель - выкладывать стабильные и ночные сборки Open Source продукта с возмжностью получения доступа к любой версии подобно тому как у Mozilla FTP устроен - там можно найти любую версию любого их продукта. Одна сборка - 10-15 МиБ.
Объем при 2-4 релизах в месяц + ночная сборка ежедневно это 500 МиБ в месяц, то есть 6 ГиБ каждый год.

Nightly builds редко когда хранят годами - скорее типично хранят месяц, затем прореживают или вовсе убивают. В общем, объемы не радикально большие - вопрос тогда скорее в том, как они используются. Если задача иметь готовый интерфейс, который можно предложить посетителю сайта, где можно будет выбирать эти файлы, ходить по каталогам и т.д. - тогда SF или GitHub releases (но они, повторюсь, для такой задачи не очень удобны, т.к. придется еще заводить раз в сутки тэг, куда все это складывать). Если задача - удобно интегрироваться с готовый сайт - я бы шел по пути S3 или чего-нибудь с S3-подобным API.

GreyCat: Спасибо за ответы, теперь более понятно куда копать. Пока в итоге склоняюсь к SF, а там посмотрим.