Size: a a a

DocOps-сообщество

2021 April 01

NP

Nikolaj Potashnikov in DocOps-сообщество
Видишь, я нашёл, как расшифровывается твой любимый rst, теперь твоя очередь
источник

II

Ivan Ievlev in DocOps-сообщество
Александр Кожин
Ребята привет. Нужен совет.
Контекст
Есть веб приложение (довольно сложный инструмент).
Внутри справка.
Сейчас эта справка лежит вместе с кодом приложения в виде asciidoc.
Собирается при сборке приложения.

Задача
Хочется чтобы справку могли править не только разработчики, но и вся команда.

Варианты
Можно оставить как есть, что не очень удобно, т.к. смешивается код и дока.
Можно вынести в отдельный репозиторий. Но тогда вопрос: как хранить сгенерированную доку (либо покаывать отдельным static ресурсом, либо встраивать копированием в приложение).

Как обычно делают?
Можно вообще не собирать доки, а рендерить онлайн с помощью https://asciidoctor.org/docs/asciidoctor.js/
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
даже при рендеринге онлайн собирать всё равно нужно, иначе нарушение разметки будет сразу ломать документацию
источник

RG

Ramil G in DocOps-сообщество
Александр Кожин
Как другие делают интересно.
мы держали доки в отдельной репе. При релизе CI генериn набор html и выкладывает на nginx как статичный сайт. техписы смотрят как будет рендериться во время создания доки сами у себя в локальных компах, кто в vscode, кто в asciidocFX. Я лично использую расширение Хрома Asciidoctor.js Preview.
источник

FM

Fox Mulder in DocOps-сообщество
А я из вс_кода смотрю )
источник
2021 April 02

RG

Ramil G in DocOps-сообщество
Fox Mulder
А я из вс_кода смотрю )
В вскод площадь окна жалко на предпросмотр тратить. На 14 дюймовом экране проще переключиться на хром.
источник

FM

Fox Mulder in DocOps-сообщество
ctrl+alt+s == билд html-страницы
источник
2021 April 05

AN

Andrew Nilove 💔 in DocOps-сообщество
#вопрос
@Nick_Volynkin , доброго дня! Порекомендуйте пожалуйста статью или доклад, где описаны варианты хранения и сборки документации для многорепозитарных систем. Проблема в следующем: у текущего работодателя очень большой зоопарк по количеству репозитариев и стеков. Хранят исходники в гитлабе (несколько отдельных хранилищ с разными адресами) и битбакете. Стек очень разнообразный: .net, Java, Kotlin, Swift. Конечное решение представляет из себя набор фронтовых клиентов, монолитных приложений, микросервисов (причем написанных на разном стеке в т.ч.).

Например, в стеке Javа уже сделаны некоторые попытки сделать документацию на ASCIIDoctor + Spring RestDocs. В других стека ситуация похуже.

Т.е. на первом этапе хотелось бы определиться с местом хранения документации по интеграционным решениям и определить способ сборки общей документации по множеству репозитариев.
источник

NV

Nick Volynkin in DocOps-сообщество
Привет, я попозже смогу ответить )
источник

FM

Fox Mulder in DocOps-сообщество
Andrew Nilove 💔
#вопрос
@Nick_Volynkin , доброго дня! Порекомендуйте пожалуйста статью или доклад, где описаны варианты хранения и сборки документации для многорепозитарных систем. Проблема в следующем: у текущего работодателя очень большой зоопарк по количеству репозитариев и стеков. Хранят исходники в гитлабе (несколько отдельных хранилищ с разными адресами) и битбакете. Стек очень разнообразный: .net, Java, Kotlin, Swift. Конечное решение представляет из себя набор фронтовых клиентов, монолитных приложений, микросервисов (причем написанных на разном стеке в т.ч.).

Например, в стеке Javа уже сделаны некоторые попытки сделать документацию на ASCIIDoctor + Spring RestDocs. В других стека ситуация похуже.

Т.е. на первом этапе хотелось бы определиться с местом хранения документации по интеграционным решениям и определить способ сборки общей документации по множеству репозитариев.
аскидок + антора.
В анторе пилишь пайплайн по сбору док из разных реп.
Я бы даже написал, что антора заточена под мультирепы.
источник

AN

Andrew Nilove 💔 in DocOps-сообщество
Fox Mulder
аскидок + антора.
В анторе пилишь пайплайн по сбору док из разных реп.
Я бы даже написал, что антора заточена под мультирепы.
а как реализовать сборку Spring RestDocs, если они лежат в другом репозитарии? Просто джобой собирать в отдельный контейнер?
источник

FM

Fox Mulder in DocOps-сообщество
скорее отказаться от спингра.
Антора сам по себе веб-генератор. Внутри анторы есть пайплайн, в котором прописывается ci
источник

M

Maeg in DocOps-сообщество
Fox Mulder
А я из вс_кода смотрю )
А какой плагин это позволяет делать?
источник

FM

Fox Mulder in DocOps-сообщество
Maeg
А какой плагин это позволяет делать?
ctrl+alt+s
ну и само собой
asciidoctor.asciidoctor-vscode
источник

M

Maeg in DocOps-сообщество
Fox Mulder
ctrl+alt+s
ну и само собой
asciidoctor.asciidoctor-vscode
а, у меня reStructuredText :( локально собираю каждый раз
источник

FM

Fox Mulder in DocOps-сообщество
Maeg
а, у меня reStructuredText :( локально собираю каждый раз
я думаю и в rst есть средство, чтобы не билдить каждый раз.
я год назад кстати смотрел видео на ютубе, где поднимался сервер на node.js и все изменения в коде были видны онлайн на странице.
Ссылку на видео не просите, сам найти не могу (
источник

M

Maeg in DocOps-сообщество
Fox Mulder
я думаю и в rst есть средство, чтобы не билдить каждый раз.
я год назад кстати смотрел видео на ютубе, где поднимался сервер на node.js и все изменения в коде были видны онлайн на странице.
Ссылку на видео не просите, сам найти не могу (
вот я тоже видела скриншоты, но плагин не нашла. Может, чья-то внутренняя разработка - в итоге решила я.
источник

NV

Nick Volynkin in DocOps-сообщество
Fox Mulder
я думаю и в rst есть средство, чтобы не билдить каждый раз.
я год назад кстати смотрел видео на ютубе, где поднимался сервер на node.js и все изменения в коде были видны онлайн на странице.
Ссылку на видео не просите, сам найти не могу (
У нас в Тарантуле такое есть, там внутри sphinx-autobuild
источник
2021 April 07

FM

Fox Mulder in DocOps-сообщество
А есть кто с keycloak работает?
источник

S

Sergey in DocOps-сообщество
мы работали, но не сказать чтоб большие гуру в нем.  Как openID Connect работает.  Gatekeeper сейчас лучше уже не использовать
источник