В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

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

684 membersпожаловаться на группу
2020 June 19

BM

B M in DocOps-сообщество
Vadim Smelyanskiy
И к вопросу о пайплайне, соответственно

Если исправлять опечатки или ещё какие ошибки только в итоговой документации, не перезапуская пайплайн, то у нас раздваиваются источники истины, и это уже проблема
Почему же? Запускается, допустим, sphinx doc, который генерирует доку с уже исправленной опечаткой. Всё, источник истины один.
источник
11:43пожаловаться#1

VS

Vadim Smelyanskiy in DocOps-сообщество
B M
Почему же? Запускается, допустим, sphinx doc, который генерирует доку с уже исправленной опечаткой. Всё, источник истины один.
Не совсем понял, Sphinx Doc как-то умеет фиксы в последних этапах (на самом сайте с докой) переносить в RST исходник?
источник
11:43пожаловаться#2

VS

Vadim Smelyanskiy in DocOps-сообщество
Или где для вас начинается пайплайн?
источник
11:44пожаловаться#3

BM

B M in DocOps-сообщество
Представим проект. В нём есть две директории docs и src. В docs лежат .rst файлы, в src, соответственно, лежит код. Мы редактируем docs/example.rst и отправляем изменения в develop. Т.к. файлы в директории src не изменились, то на шаге build происходит только билд документации из rst в html, а на этапе deploy только отправка html артефактов на сервер с документацией.
источник
11:46пожаловаться#4

VS

Vadim Smelyanskiy in DocOps-сообщество
B M
Представим проект. В нём есть две директории docs и src. В docs лежат .rst файлы, в src, соответственно, лежит код. Мы редактируем docs/example.rst и отправляем изменения в develop. Т.к. файлы в директории src не изменились, то на шаге build происходит только билд документации из rst в html, а на этапе deploy только отправка html артефактов на сервер с документацией.
Да, это хорошее решение, но мне кажется Том не про эту проблему в первую очередь говорит
источник
11:50пожаловаться#5

BM

B M in DocOps-сообщество
Ну, я ещё внимательнее почитаю позже, да.
источник
11:50пожаловаться#6

FM

Fox Mulder in DocOps-сообщество
Ivan Cheban
Некоторые стейкхолдеры предпочитают менее технические инструменты: например, Quip или Google Docs.
Г. докс очень быстрый инструмент совместной работы. В нём есть свои плюсы.
источник
15:00пожаловаться#7

И

Иван in DocOps-сообщество
B M
Я пробежал по-диагонали, он вроде не говорит, что не нужно, он говорит, что вы слишком переигрываете, всё таки не надо запускать весь пайплайн проекта, если изменяете опечатку в документации. Но это очевидно, я считаю.
а какая разница, если пайплайн автоматический, как у кодеров?
источник
15:01пожаловаться#8

BM

B M in DocOps-сообщество
Иван
а какая разница, если пайплайн автоматический, как у кодеров?
Время между коммитом фикса в доке и доставкой фикса до сервера со скомпилированной докой сильно увеличивается, если запускать все задачи. Плюс у кого-то запуск всего пайплайна может быть довольно затратной операцией по ресурсам. Да и в целом много нюансов может быть.
источник
15:16пожаловаться#9

И

Иван in DocOps-сообщество
B M
Время между коммитом фикса в доке и доставкой фикса до сервера со скомпилированной докой сильно увеличивается, если запускать все задачи. Плюс у кого-то запуск всего пайплайна может быть довольно затратной операцией по ресурсам. Да и в целом много нюансов может быть.
нюансов много, да. оптимизируются по мере необходимости

а пайплайны обычно запускаются на удалённой тачке, она на всех одна — зачем “у кого-то” запускать?
источник
15:19пожаловаться#10

BM

B M in DocOps-сообщество
А я не говорил про запуск у кого-то. Конечно на специальных раннерах запускаются задачи.
Я понимаю, что оптимизируются, но вы всё равно не достигните такой скорости, как если будете только компилировать и деплоить доку, без запуска посторонних задач.
источник
15:20пожаловаться#11

И

Иван in DocOps-сообщество
B M
А я не говорил про запуск у кого-то. Конечно на специальных раннерах запускаются задачи.
Я понимаю, что оптимизируются, но вы всё равно не достигните такой скорости, как если будете только компилировать и деплоить доку, без запуска посторонних задач.
ну конечно, тут палка о трёх концах

исправить опечатку в гуглдоке в любом случае быстрее, чем исправить опечатку в репозитории. даже без пайплайнов
источник
15:21пожаловаться#12

KC

Kseniya Chudakova in DocOps-сообщество
B M
А я не говорил про запуск у кого-то. Конечно на специальных раннерах запускаются задачи.
Я понимаю, что оптимизируются, но вы всё равно не достигните такой скорости, как если будете только компилировать и деплоить доку, без запуска посторонних задач.
так, а может, создать пайплайн, который учитывает ваше право на ошибку.  и не запускает дополнительные таски без необходимости
источник
15:37пожаловаться#13

KC

Kseniya Chudakova in DocOps-сообщество
изи вей
источник
15:37пожаловаться#14

BM

B M in DocOps-сообщество
Kseniya Chudakova
изи вей
А я выше именно об этом и писал. Я тоже вижу именно такое решение. Не нужно запускать, что не нужно)
источник
15:41пожаловаться#15

KC

Kseniya Chudakova in DocOps-сообщество
B M
А я выше именно об этом и писал. Я тоже вижу именно такое решение. Не нужно запускать, что не нужно)
извините, читаю по диагонали) да, тут вопрос процессов в конманде/компании
источник
15:48пожаловаться#16

DL

Dmytro Lispyvnyi '(🌲... in DocOps-сообщество
Драсте мне тут ссылоньку дали, я решил зайти посидеть, если никто не против
источник
23:13пожаловаться#17

DL

Dmytro Lispyvnyi '(🌲... in DocOps-сообщество
Иван
ну конечно, тут палка о трёх концах

исправить опечатку в гуглдоке в любом случае быстрее, чем исправить опечатку в репозитории. даже без пайплайнов
о, а можно я сразу не соглашусь и поспорю? (только в контекст попробую врубиться)
источник
23:13пожаловаться#18

И

Иван in DocOps-сообщество
Dmytro Lispyvnyi '(🌲 🍺)
о, а можно я сразу не соглашусь и поспорю? (только в контекст попробую врубиться)
источник
23:14пожаловаться#19

DL

Dmytro Lispyvnyi '(🌲... in DocOps-сообщество
Иван
так вот, какие действия нужны для того, чтобы поправить ошибку в репозе?
Открыл файл, прыгнул на нужное место, сохранил, stage/commit/push (а ещё это, при желании, автоматизируется макросами или типа того)
В гуглодоксах - мучительно ищешь нужный файл(хотя их на порядки меньше, чем файлов в репозитории), нужное место тоже приходится искать O(n) поиском
источник
23:19пожаловаться#20