Выкладка в nuget происходит на основе триггера на тег определённого формата
v1.0.0
- формат релизная версия на ветке masterv1.0.0-rc1
- формат тестовой/альфа/бета версии на любой ветке
Тег можно создать через git(нужно запушить его в origin) создание тега и пуш в remote или через раздел releses(альфа версии нужно помечать соответсвующей галкой).
- Создаем ветку, пушим изменения, создаем pull request.
- Вешаем на ветку тег например
v1.0.2-new-auth-12
- Срабатывает workflow билдит и пушит версию(берёт из названия тега) в nuget.
- По готовности мерджим ветку в master.
- Вешаем релизный тег на нужный коммит мастера. Нужно обязательно описать изменения внесённые этим релизом в release notes Здесь лучше воспользоваться интерфейсом гитхаба, там удобнее редакитровать текст.
- Срабатывает релизный workflow билдит и пушит в нугет релизную версию.
- В разделе Releses появляется информация о нашем релиз и release notes.
Чтобы зарегистрировать сервис в консуле нужно:
в appsettings.json
поместить блок
"ConsulRegistratorOptions": {
"ProvideEnvironment": "env",
"ConsulServiceOptions": [
{
"ServiceName": "your-service-name",
"Tags": ["env"],
"Check": {
"HTTP": "/api/health/service",
"DeregisterCriticalServiceAfter": "00:00:05",
"Interval": "00:00:05",
"Timeout": "00:00:02"
}
}
]
}
Да, там массив. Да, можно зарегать один сервак под разными тегами, именами, всем. Это необходимо в сервиса нотификаций, для версионирования старых мобильных приложений, которые ходят без прокси и не выживают после смены контрактов.
Далее осталось только добавить в Startup.cs
services.AddConsul()
За основу взята работа с HttClientFactory
из atisu.services.common
, но добавлены следующие extensions:
services.AddConsulHttpClient<TAdapter, TServiceOptions>
Методы делают почти все то же самое, что и services.AddCustomHttpClient<>
, но дополнительно:
- Добавляется
ServiceAsClientName
хедер во все запросы - Добавляется
HttpConsulHandler
, который на каждый запрос (retry) получает ip+port инстанса изConsulServiceAddress