Мой вопрос был в ведении части страниц вики с использованием подхода "docs as a code".
Для конкретики - пусть у меня есть репозиторий в котором лежат markdown/asciidoc страницы и я хочу публиковать их на вики. Какие это сделать?
Например в конфлюэнсе никаких инструментов для этого нет официальных, но есть апи, поэтому существуют много опенсорс тулов которые через апи заливают это на лету конвертируя в confluence storage формат. Например - https://github.com/zeldigas/text2confl
В целом вы правы, но у меня не вяжутся факты из статьи о большом объеме документации в разных форматах и "школьники владеющие Word".
Для пары страничек конечно никакой сложной системы документации не нужно, но если документации много разумно продумать структуру и вложиться в настройку "платформы" где она будет создаваться. Да это требует определенных знаний и подготовки, но часто это разовая работа которая закладывает основу а авторы документов уже работают по шаблону не сильно погружаясь в технические детали как изменения в текстовом файле преобразуются в страницу а сайте или pdf документ.
Судя по описанию задач и размера документов, тут больше напрашивается что-то типа анторы, особенно с учётом гибкой настройки стилей и возможности формирования как сайта так и pdf из одного источника
Буквально недавно в контексте проработки Docs as code вопроса выяснилось что у draw io есть оффлайн редактор который позволяет все делать вне браузера/конфлюнса сохраняя результат в переносимый svg или png (тоже вроде заявляется что остаётся редактируемым, но не проверял).
В итоге получаем вполне рабочую связку - markup language (markdown, asciidoc) + svg диаграммы. А там заливайте куда нужно (например в тот же confluence) или генерит статический сайт той же анторой.
К сожалению проблема с выбранным подходом в том что сама загрузка у вас получилось блокирующей, так как в функции вы делаете join(). Отсюда все приключения с Dispatcher.IO (который нужен только для того чтобы в корутинах выполнять код который может быть заблочен, например на операциях ввода-вывода).
Еще стоит отметить, что создавать http клиент на каждый запрос не самая хорошая идея. Обычно такие вещи шарят чтобы переиспользовать пул соединений.
С учетом вышесказанного, правильный подход был бы таким.
suspend fun getData(httpClient: HttpClient, url: String): String? {
val httpRequest = HttpRequest.newBuilder().uri(URI.create(url)).build()
return httpClient.sendAsync(httpRequest, HttpResponse.BodyHandlers.ofString())
.await().body()
}
val httpClient:HttpClient = HttpClient.newBuilder().build()
val result = measureTimeMillis {
runBlocking {
(1..10).toList().map { async { getData(httpClient, "$URL/$it") } }.awaitAll()
}
}
println("Time for requests: $result")
Если используете logback, обратите внимание на вот эту статью — https://habr.com/ru/post/524130/. Корутины подчас генерят исключения с циклами, что может быть ВНЕЗАПНЫМ сюрпризом.
Чуть больше информации (специфично про корутины) — здесь
Понятно, спасибо большое! Было бы круто иметь что-то подобное в виде опен сорс проекта, чтобы не переизобретать велоспеды заново, но это так — мечты :).
Наверное, последний вопрос — реализацию отслеживания зависмостей вы тоже делали силами modernizer'а? Если да, то какие плюсы для себя видели по сравнению с тем же renovate который можно on-premise развернуть (ну кроме опять же унификации инструмента хоть и ценой поддержки своей собственной реализации)?
Доклад очень интересный, но жалко что часть про патчи действительно была опущена. Очень хотелось бы технических подробностей, как это делали: свелось ли это к условному наивному патч файлу (да, который можно автоматически применить гитом) за счет обозначенной унификации в сервисах или все же изменение представляет собой более сложный структурный поиск по коду и его модификацию.
Выглядит что эта часть содержат наибольшую "добавленную стоимость" по сравнению с распространенными системами типа dependabot/renovate.
Интересно насколько встроенные плагины бута справляются с правильным переиспользованием слоев в случае CI системы и большого числа агентов. До версии 2.3 с её инструментами сборки образов надо было приложить некоторые усилия для этого. Чуть больше года назад писал про это
Выглядит очень интересным вариантом для случаев, когда супер гибкости сборки не требуется и единственное чего хочется — большей лаконичности и компактности от pom файла
Если бы не пример с использованием aws cli без --endpoint в статье, я бы предположил, что это кусок облака mail.ru. У них есть s3-совместимое хранилище (со своими особенностями, но для простых операций не отличить)
Когда изучали проблему невоспроизводимости на билд агентах, эта версия рассматривалась и даже некоторое время после исправления настоящей проблемы использовали строчку find . -exec touch -t 200001010101 {} \; на распакованных файлах, но позже выяснили что она ничего не улучшает (по крайней мере на тех сценариях что у нас есть).
Jib наверное стоит действительно посмотреть, выглядит интересно. Спасибо за наводку.
Основная причина — преемственность статьи из спрингового блога. Я специально не трогал базовый образ, чтобы не вводить новых сущностей.
В целом вопрос выбора базового образа вопрос отдельный, но статья больше про оптимизацию разницы между образами, как вы можете видеть из графика в последнем разделе — какой бы базовый образ не был, мы получаем очень мелкие диффы. Это конечно не отменяет необходимость первичной загрузки на сервера, но при условии что прилаг много и все они шарят базовый образ его загрузка будет выполнена один раз.
ага
вопрос не в миграции.
Мой вопрос был в ведении части страниц вики с использованием подхода "docs as a code".
Для конкретики - пусть у меня есть репозиторий в котором лежат markdown/asciidoc страницы и я хочу публиковать их на вики. Какие это сделать?
Например в конфлюэнсе никаких инструментов для этого нет официальных, но есть апи, поэтому существуют много опенсорс тулов которые через апи заливают это на лету конвертируя в confluence storage формат. Например - https://github.com/zeldigas/text2confl
Как у вас с этим?
Docs as a code поддержка есть у вас или по аналогии с Confluence - выставлено апи через котороенстронними тулами нужно заливать страницы?
Интересуюсь как автор такой тулы для конфлы)
В целом вы правы, но у меня не вяжутся факты из статьи о большом объеме документации в разных форматах и "школьники владеющие Word".
Для пары страничек конечно никакой сложной системы документации не нужно, но если документации много разумно продумать структуру и вложиться в настройку "платформы" где она будет создаваться. Да это требует определенных знаний и подготовки, но часто это разовая работа которая закладывает основу а авторы документов уже работают по шаблону не сильно погружаясь в технические детали как изменения в текстовом файле преобразуются в страницу а сайте или pdf документ.
По ссылкам - на хабре есть стать по теме анторы: https://habr.com/ru/search/?q=antora&target_type=posts&order=relevance
Судя по описанию задач и размера документов, тут больше напрашивается что-то типа анторы, особенно с учётом гибкой настройки стилей и возможности формирования как сайта так и pdf из одного источника
Для cli приложений есть специальный Flow - device code.
Подробности - https://oauth.net/2/grant-types/device-code/
Яндекс был бы не яндексом без запиливания своего решения :).
Если можно поделиться, расскажите- что не устроило в имеющихся решениях.
Мы находили несколько разных - pantoon, weblate, tolgee. Пока изучаем последнюю, выглядит вполне перспективно.
Cat/tms систему свою пилите или что-то готовое нашли ?
Без злого умысла было сделано. Тем не менее это все равно достаточно автономный вариант не отвязывающий от "плагина в конфлюнсе"
И если смотреть по офф сайту ограничений не так много: https://drawio-app.com/use-draw-io-offline/
Буквально недавно в контексте проработки Docs as code вопроса выяснилось что у draw io есть оффлайн редактор который позволяет все делать вне браузера/конфлюнса сохраняя результат в переносимый svg или png (тоже вроде заявляется что остаётся редактируемым, но не проверял).
В итоге получаем вполне рабочую связку - markup language (markdown, asciidoc) + svg диаграммы. А там заливайте куда нужно (например в тот же confluence) или генерит статический сайт той же анторой.
Подключите https://github.com/Kotlin/kotlinx.coroutines/tree/master/integration/kotlinx-coroutines-jdk8. Экстеншен для CompletionStage живёт там
К сожалению проблема с выбранным подходом в том что сама загрузка у вас получилось блокирующей, так как в функции вы делаете
join(). Отсюда все приключения с Dispatcher.IO (который нужен только для того чтобы в корутинах выполнять код который может быть заблочен, например на операциях ввода-вывода).Еще стоит отметить, что создавать http клиент на каждый запрос не самая хорошая идея. Обычно такие вещи шарят чтобы переиспользовать пул соединений.
С учетом вышесказанного, правильный подход был бы таким.
Если используете logback, обратите внимание на вот эту статью — https://habr.com/ru/post/524130/. Корутины подчас генерят исключения с циклами, что может быть ВНЕЗАПНЫМ сюрпризом.
Чуть больше информации (специфично про корутины) — здесь
Понятно, спасибо большое! Было бы круто иметь что-то подобное в виде опен сорс проекта, чтобы не переизобретать велоспеды заново, но это так — мечты :).
Наверное, последний вопрос — реализацию отслеживания зависмостей вы тоже делали силами modernizer'а? Если да, то какие плюсы для себя видели по сравнению с тем же renovate который можно on-premise развернуть (ну кроме опять же унификации инструмента хоть и ценой поддержки своей собственной реализации)?
Доклад очень интересный, но жалко что часть про патчи действительно была опущена. Очень хотелось бы технических подробностей, как это делали: свелось ли это к условному наивному патч файлу (да, который можно автоматически применить гитом) за счет обозначенной унификации в сервисах или все же изменение представляет собой более сложный структурный поиск по коду и его модификацию.
Выглядит что эта часть содержат наибольшую "добавленную стоимость" по сравнению с распространенными системами типа dependabot/renovate.
Интересно насколько встроенные плагины бута справляются с правильным переиспользованием слоев в случае CI системы и большого числа агентов. До версии 2.3 с её инструментами сборки образов надо было приложить некоторые усилия для этого. Чуть больше года назад писал про это
Ещё немного некропостинга — оказывается с улучшенной поддержкой расширений, не xml'ем единым: https://github.com/takari/polyglot-maven
Выглядит очень интересным вариантом для случаев, когда супер гибкости сборки не требуется и единственное чего хочется — большей лаконичности и компактности от pom файла
Если бы не пример с использованием aws cli без
--endpointв статье, я бы предположил, что это кусок облака mail.ru. У них есть s3-совместимое хранилище (со своими особенностями, но для простых операций не отличить)Когда изучали проблему невоспроизводимости на билд агентах, эта версия рассматривалась и даже некоторое время после исправления настоящей проблемы использовали строчку
find . -exec touch -t 200001010101 {} \;на распакованных файлах, но позже выяснили что она ничего не улучшает (по крайней мере на тех сценариях что у нас есть).Jib наверное стоит действительно посмотреть, выглядит интересно. Спасибо за наводку.
Основная причина — преемственность статьи из спрингового блога. Я специально не трогал базовый образ, чтобы не вводить новых сущностей.
В целом вопрос выбора базового образа вопрос отдельный, но статья больше про оптимизацию разницы между образами, как вы можете видеть из графика в последнем разделе — какой бы базовый образ не был, мы получаем очень мелкие диффы. Это конечно не отменяет необходимость первичной загрузки на сервера, но при условии что прилаг много и все они шарят базовый образ его загрузка будет выполнена один раз.