Comments 12
Вы можете сделать chmod +x на нужные файлы локально и закоммитить это в гит (он умеет трекать execution permission), нет необходимости делать это в .travis.yml :)
Спасибо за полезное добавление. Просто осталась старая привычка со времён SVN, поэтому и добавляю на автомате chmod +x куда следует и не следует.
deploy:
- provider: releases
api_key:
secure: [hash]
file:
- linux.zip
- win.zip
skip_cleanup: true
on:
condition: $TRAVIS_OS_NAME == linux
tags: true
В четвертом абзаце об этом говорится, но автор почему-то считает нелогичным работать через метки и выпуски, а хочет грузить двоичные артефакты в ветку самого репозитория.
То есть Вы действительно создаете новый тег на каждый коммит и после каждого коммита создаете новую версию в разделе Release?
Так моя заметка и посвящена именно ежедневным сборкам. Просто я вместо hockeyapp или другого внешнего провайдера использую специальную ветку самого проекта на GitHub.
Для ежедневных (читай оч частых) сборок действительно лучше не захламлять репозиторий тегами, иначе будет боль как в https://github.com/JetBrains/kotlin/releases :(
Мне не очень понятно почему вы делаете билд на каждый коммит. Вы же с git работаете и билд у вас на push запускается. Зачем вам пушить каждый коммит в отдельности? Может вы ещё от svn не отвыкли?
С гитом обычно так — поработали немного, сделали несколько коммитов, дошли до какой-то логической точки и запушили.
Разве вы делаете не так?
Если это логическая точка, то почему не сделать релиз, пускай и микро? Вообще, новая сборка это и есть релиз, пускай и не стабильный.
Проблема засорения репозитория, как в примере от Artem_zin, связана с тем, что у них не очень удачно выбран алгоритм релизов и именование меток. Вместо:
- build-1.1.60-dev-17
- build-1.1.60-dev-18
- build-1.1.60-dev-19
Можно былоб писать проще
- 1.1.60.17
- 1.1.60.18
- 1.1.60.19
Последняя цифра это номер сборки в текущем релизе. Релизы сборки можно создавать автоматом на Travis CI. Не обязательно явно делать релиз.
Если релизы создавать автоматом, то может возникнуть проблема, когда захочется сделать полноценный релиз. Придется пошаманить немного.
А теперь о главном. О преимуществах подхода через релизы и о недостатке вашего решения.
Проблема в том, что у вас сборка хранится в репозитории и отличить одну от другой можно только по хешу коммита. После того как пользователь скачает сборку, он ни как не сможет определить какая у него версия. Он ни как не сможет определить на сколько версия, скачанной им сборки, устарела. Если он обнаружит багу в приложении, то он ни как не сможет вам сказать в какой версии произошла ошибка. Всё что он может, это приложить к тикету архив со сборкой и вам уже придется ручками, по хошсумме файла искать сборку в истории коммитов.
Возможно я утрирую и есть какой-то более человеческий способ.
Я же лишь хочу сказать, что возможно для контроля удобнее выкладывать не файл myapp.apk, а myapp_1.1.60.19.apk или myapp_1.1.60.19.zip.
Я не критикую, я только предлагаю.
Спасибо за вдумчивый и развёрнутый комментарий. На первый взгляд, Вы все пишите правильно. Лишь два момента не дают мне покоя.
Во-первых, Вы странным образом отождествляете git с двухстадийной методикой работы и противопоставляете эту методику svn. Точно так же, как и в git, двухстадийные коммиты реализуются в svn штатными средствами: создаем ветку, коммитим туда, не забывая постоянно синхронизировать её с trunk-веткой, потом делаем svn reintegrate (что соответствует git push), после чего ветку удаляем (svn remove). Это то же самое в организационном плане, что и git commit/push, с двумя небольшими отличиями. Первое, эту акцию в svn нужно планировать заранее. Второе — промежуточные коммиты в git остаются на рабочем месте (в локальном репозитории), а в svn попадают в удалённый репозиторий. Именно поэтому использование git (именно git, как Вы это описали — поработали немного, сделали несколько коммитов, дошли до какой-то логической точки и запушили) у нас в фирме запрещено. И на это есть веская причина — если разработчик сделал 99% задачи, но не сделал ни одного git push, это все остаётся на его рабочем месте. Если с рабочим компом что-то случится, результаты его работы потеряны навсегда. Поэтому только svn, но в режиме множественных короткоживущих веток и svn reintegrate. Так что от svn я не отвык и еще лет 10 минимум не отвыкну.
Во-вторых, Вы упустили из виду очень полезный совет — «не плоди сущностей без надобности». Вы на ровном месте ввели совершенно ненужную сущность — микро-релиз. Сейчас поясню. В моем случае, репозиторий завязан на F-Droid, то есть при создании метки F-Droid автоматически собирает и публикует релиз приложения. То есть сущность релиза — это то, что официально опубликовано на F-Droid.
Что такое автоматическая сборка (snapshot) — тоже всем понятно. Это нечто без версии, но полностью соответствующее в данный момент исходному коду. Эта сущность уже существует, как минимум, на рабочей станции разработчика. Почему бы её просто не опубликовать?
Snapshot, кстати, хорошо вписывается в agile-модель. Релиз — это результат спринта. Автоматические сборки — отработка стори-поинтов. Стори-поинт готов, закоммичен, тестировщик тестирует только его, и какая-либо искусственная нумерация здесь мало что даёт.
То есть то, что вы описали как недостаток (сборка хранится в репозитории и отличить одну от другой можно только по хешу коммита), я расцениваю, как достоинство. Конечного пользователя эти сборки не касаются, для него есть официальные релизы. А тестировщик и так знает, что делает. Если начинать нумеровать (myapp_1.1.60.19.apk), то через год таких файлов будут сотни. Что с ними делать? Удалять? До какого времени?
Ваше предложение, конечно же, будет во многих случаях очень хорошо работать. Но мой метод, мне кажется, просто проще и понятней.
Travis CI: автоматическая загрузка собранных модулей на GitHub