01.10.2011 19:08, Aleksey Avdeev пишет:
> 01.10.2011 11:34, Денис Смирнов пишет:
...
>> Так в .gear кладутся скрипты для cronbuild. Если есть какие-то общие
>> компоненты -- так их можно вынести отдельно и использовать.
>>
>> Сейчас-то у нас пакетов собирающихся с помощью cronbuild ой как мало.
> 
>   Сейчас в эту компанию я moodle* добавляю.
> 
> PS: Похоже мне придётся патчить cronbuild-rear для этого.

  Прототип cronbuild`овских скриптов готов (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=tree;f=.gear;h=9e9b7b43b93dd705a12bddb0f7547ea194e23b98;hb=3df59e6b4bb7498697a01cabd919cd6166cc2d30>)
и тестовое обновление сборочного бранча gear-cronbuild`ом выполнено (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=commit;h=40041eb6e5a8ed63743a928969b3dfe8993b3145>).

  По свежим следам:

1. Всю логику пришлось выносить в cronbuild-update-source (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=blob;f=.gear/cronbuild-update-source;h=e65098fe3c6a1241c593ac61c4756ace0b5a3f10;hb=3df59e6b4bb7498697a01cabd919cd6166cc2d30>),
а cronbuild-{update-version,add-changelog} -- низводить до состаяния
заглушек, тупо выполняющих exit 0 (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=blob;f=.gear/cronbuild-update-version;h=a3c4c486aa2464f097cd5716ea817121b8ad44d6;hb=3df59e6b4bb7498697a01cabd919cd6166cc2d30>).
Причины опишу ниже.

2. При использовании gear-commit -m <msg> _необходимо_ учитывать
находящийся в потрохах gear-commit`а eval => сложные <msg> нужно квотить
=> это нужно учитывать в cronbuild-commitmsg (в моём случаи -- см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=commitdiff;h=3df59e6b4bb7498697a01cabd919cd6166cc2d30>)...
Думаю, стоит перенести оквочивание на уровень gear-cronbuild*.

3. Думаю, в скрипты cronbuild-{commitmsg,tag{name,msg}} стоить
передавать имя спека.

  Для п. п. 2-3 готов подготовить патчи.

  По п. 1 (обещание данное выше).

  gear-cronbuild заточен на реализацию следующего алгоритма:

1. Обновление сорцов (cronbuild-update-source).

2. Правка спека на предмет версий (cronbuild-update-version).

3. Обновление changelog`а (cronbuild-add-changelog).

4. Финальный (сборочный) коммит (gear-commit).

  Причём, подразумевается что всё действо происходит в одном бранче
(если cronbuild-update-source не внесёт изменений в начальный бранч --
git diff изменений не покажет => gear-cronbuild-apply-hooks обновления
сорцов не заметит). П. 3 должен выполнить подготовку к коммиту, но не
выполнять его (иначе gear-commit в п. 4 завершиться с ошибкой).

  Я же использую пачку бранчей, и следующий алгоритм:

1. Обновление бранчей с сорцами. Это последовательность pull`ов и
мержей, _не_затрагивающая_ основной (сборочный) бранч.

2. Правка спека на предмет версий в основном бранче (в конечном итоге).

3. Мерж сорцовых бранчей в основной (-s ours).

4. Выставление тегов на исходники.

5. gear-update-tag

6. Финальный (сборочный) коммит.

  В общем, законопачивание п. п. 1-5 в cronbuild-update-source (хотя, по
хорошему, там только п. 1 место) позволило применить данный алгоритм
cronbuild`ом, и реализовать откат на исходное состояние бранчей (если
что-то пошло не так) малой кровью.

-- 

С уважением. Алексей.