1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/vcs-all-in-one-GitVersion

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.md 8.5 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 12.03.2025 11:52 c20ed76

Вклад в проект GitVersion

Мы любим вклады в наш проект. Чтобы начать вносить свой вклад, вам может потребоваться:

После того, как вы узнаете, как создавать pull requests и имеете задачу для выполнения, просто оставьте комментарий, что вы будете работать над ней. Если вы не сможете завершить задачу, пожалуйста, оставьте ещё один комментарий, чтобы другие могли взяться за неё.

Открытые вопросы также приветствуются, а неудачные тесты особенно ценятся.

Правила внесения вклада

  • Попробуйте использовать feature branches вместо разработки на master.
  • Пожалуйста, включите тесты, покрывающие изменения.
  • Документация хранится в репозитории в папке docs. Ознакомьтесь с файлом readme документации для получения руководства по улучшению документации и включите обновления документации с вашим pull request.

Как это работает

См. как это работает в документации GitVersion## Написание тестов

Мы сделали написание тестов в GitVersion очень простым. Большинство тестов, интересующих вас, находятся в GitVersionCore.Tests\IntegrationTests.

Для каждого типа ветки существует класс сценария. Например, MasterScenarios, FeatureBranchScenarios и т.д.

1. Найдите подходящий класс сценария

Найдите место, где логически должна располагаться ваша задача. Или создайте новый класс сценария, если он не подходит ни к одному конкретному месту.

2. Создайте метод теста

Мы используем NUnit, так что просто создайте описательный метод теста и пометьте его атрибутом [Test]

3. Используйте фикстуру

У нас есть несколько фикстур для различных сценариев.

  • EmptyRepositoryFixture — предоставляет вам пустой git-репозиторий для начала;
  • RemoteRepositoryFixture — локальный репозиторий, отслеживающий тестовый удалённый репозиторий. Удалённый репозиторий доступен через свойство Repository, локальный через LocalRepository;
  • BaseGitFlowRepositoryFixture — репозиторий, настроенный для GitFlow (имеет ветку develop, которая уже проверена и готова к работе). Вы можете использовать фикстуру просто используя её. Например,
using (var fixture = new EmptyRepositoryFixture(new Config()))
{
}

4. Настройка конфигурации

Если вы используете нестандартную конфигурацию, просто измените класс Config перед созданием фикстуры.

5. Написание сценарияУ нас есть несколько расширяемых методов от IRepository, чтобы сделать тестирование на уровне потока простым и не беспокоиться о создании/фиксации файлов.

Пример теста выглядит следующим образом:

fixture.Repository.MakeATaggedCommit("1.0.0");
fixture.Repository.CreateBranch("feature-test");
fixture.Repository.Checkout("feature-test");
fixture.Repository.MakeACommit();
fixture.Repository.MakeCommits(4);

fixture.AssertFullSemver("1.0.1-test.1+5");

Последняя строка является наиболее важной. AssertFullSemver запустит GitVersion и проверит, что полная версия SemVer, которую он рассчитывает, совпадает с вашими ожиданиями.

6. Отправьте запрос на включение с проваленным тестом

Лучше всего включите исправление, но проваленный тест — отличное начало.

Процесс сборки / выпускаМы используем Cake для нашего процесса сборки и деплоя. Установленный способ работы процесса сборки/выпуска следующий:

  1. Мы создаем выпускные артефакты на AppVeyor.
  2. Войдите в AppVeyor.
  3. Разверните последнюю сборку мастер-ветки. docs/input/docs/img/release-1-deploy.png
  4. Выберите GitVersion release; при нажатии кнопки "развернуть" будет создано нераскрытое релизное сообщение на GitHub, это не создаст Git-тэг. Этот шаг необходим для проверки релиза и заметок перед тем, как нажать кнопку. docs/input/docs/img/release-2-deploy.png
  5. Все артефакты должны успешно загрузиться. docs/input/docs/img/release-3-deploy.png
  6. Перейдите к релизам на GitHub, там должна быть черновая версия релиза, скачайте копию заметок релиза. docs/input/docs/img/release-4-deploy.png
  7. Отредактируйте релиз и выполните следующие действия:
    1. Удалите метаданные сборки из тэга и заголовка (плюс и все после него).
    2. Вставьте скачанные заметки релиза, вы можете очистить их, если хотите, иначе могут остаться открытые вопросы и т.д.
    3. Отметьте галочкой поле предварительной версии, если это предварительная версия.
    4. Нажмите кнопку "Опубликовать".
  8. Опубликуйте тэги (Git-тэг) релизного коммита, что запустит ещё одну сборку AppVeyor, которая собирает только тэги. Эта сборка использует deploy.cake. Она загружает артефакты с этого релиза на GitHub, затем выполняет релиз.

DockerЭто шаг ручной выпустки после выпуска. Сначала скачайте соответствующий ZIP-файл и поместите его в папку releaseArtifacts в репозитории GitVersion, затем выполните:

docker build . --build-arg GitVersionZip=GitVersion_<VERSION>.zip --tag gittools/gitversion

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/vcs-all-in-one-GitVersion.git
git@api.gitlife.ru:oschina-mirror/vcs-all-in-one-GitVersion.git
oschina-mirror
vcs-all-in-one-GitVersion
vcs-all-in-one-GitVersion
master