На данный момент нас интересует интеграция с gitea, но строить систему необходимо через абстрактное апи, так чтобы в будущем добавить интеграцию с git-hooks, так и с другими репозиториями, в частности gitlab, а в будущем и hg.
От интеграции на первом уровне нужно связывание коммитов с задачами, при коммите в ветку описание коммита должно копироваться на соответствующую вкладку активности.
Этап задачи должен уметь запрещать коммиты в ветку, если этап не предполагает работу над задачей. (это должно гибко настраиваться, так как иногда такие коммиты все же необходимы.
Было бы не плохо дать возможность удалять ветки задач, когда задача закрыта.
При реализации версионности, необходимо в описании закрытой версии строить ссылку на тег релиза. Для репозиториев, имеющих веб-морду, стоит предзаполнять ссылками на задачу их MR и релизы.
Если репозиторий это поддерживает, в интерфейсе появятся кнопки создать Merge Request. При закрытии версии сразу проставлять её тег в репозитории,…
На данный момент нас интересует интеграция с gitea, но строить систему необходимо через абстрактное апи, так чтобы в будущем добавить интеграцию с git-hooks, так и с другими репозиториями, в частности gitlab, а в будущем и hg.
От интеграции на первом уровне нужно связывание коммитов с задачами, при коммите в ветку описание коммита должно копироваться на соответствующую вкладку активности.
Этап задачи должен уметь запрещать коммиты в ветку, если этап не предполагает работу над задачей. (это должно гибко настраиваться, так как иногда такие коммиты все же необходимы.
Было бы не плохо дать возможность удалять ветки задач, когда задача закрыта.
При реализации версионности, необходимо в описании закрытой версии строить ссылку на тег релиза. Для репозиториев, имеющих веб-морду, стоит предзаполнять ссылками на задачу их MR и релизы.
Если репозиторий это поддерживает, в интерфейсе появятся кнопки создать Merge Request. При закрытии версии сразу проставлять её тег в репозитории, а в случае gitea - создавать релиз.
Стоит подумать и предусмотреть дальнейшее развитие системы, и как хранилища репозиториев. Т.е. вместо подключения внешней системы можно будет хранить репозитори прямо в tndt (при этом весь код работы с репозиторием стоит делать минимум в отдельном модуле, а лучше в параллельном проекте, чтобы не тянуть эту функциональность в установке, где используется внешгний репозиторий, а tndt используется только как багтреккер)