KC
Разные ветки в git
это ок, но как при этом реализовать переключатель на сайте?
Size: a a a
2019 July 25
R
в нашей конторе это вопрос не моего ума, но вообще у нас просто собираются разные билды в тим сити с несколькими версиями документации
R
+ к сайту прикручен скрипт, который подставляет путь в зависимости от выбранной пользователем версии
R
но это все homebrew-решения
NV
это ок, но как при этом реализовать переключатель на сайте?
А, это работа фронтендера
KC
в нашей конторе это вопрос не моего ума, но вообще у нас просто собираются разные билды в тим сити с несколькими версиями документации
спасибо!
KC
А, это работа фронтендера
у меня пока что исследовательский интерес) потом с фронтами будем решать, да
A
у меня пока что исследовательский интерес) потом с фронтами будем решать, да
у вас какой формат/движок? у нас sphinx-doc/rst и тоже стоит аналогичная задача на фронт
A
мы вплотную подошли к поддержке как минимум двух релизов, и надо реализовывать версионность справочной системы
NV
В целом так:
Разные ветки git для разных версий, из них собираются разные версии доки. Каждая падает в свою папку на сервере, оттуда их nginx показывает пользователям.
На каждую страницу при сборке врезается выпадающий список или переключатель, в котором выделена текущая версия и есть другие.
Переключение по языкам — такой же список.
Разные ветки git для разных версий, из них собираются разные версии доки. Каждая падает в свою папку на сервере, оттуда их nginx показывает пользователям.
На каждую страницу при сборке врезается выпадающий список или переключатель, в котором выделена текущая версия и есть другие.
Переключение по языкам — такой же список.
R
В целом так:
Разные ветки git для разных версий, из них собираются разные версии доки. Каждая падает в свою папку на сервере, оттуда их nginx показывает пользователям.
На каждую страницу при сборке врезается выпадающий список или переключатель, в котором выделена текущая версия и есть другие.
Переключение по языкам — такой же список.
Разные ветки git для разных версий, из них собираются разные версии доки. Каждая падает в свою папку на сервере, оттуда их nginx показывает пользователям.
На каждую страницу при сборке врезается выпадающий список или переключатель, в котором выделена текущая версия и есть другие.
Переключение по языкам — такой же список.
собственно, примерно аналогично все это и выглядит у нас
A
В целом так:
Разные ветки git для разных версий, из них собираются разные версии доки. Каждая падает в свою папку на сервере, оттуда их nginx показывает пользователям.
На каждую страницу при сборке врезается выпадающий список или переключатель, в котором выделена текущая версия и есть другие.
Переключение по языкам — такой же список.
Разные ветки git для разных версий, из них собираются разные версии доки. Каждая падает в свою папку на сервере, оттуда их nginx показывает пользователям.
На каждую страницу при сборке врезается выпадающий список или переключатель, в котором выделена текущая версия и есть другие.
Переключение по языкам — такой же список.
это всё понятно) стоит вопрос, каким образом это всё реализовать
R
собирать в отдельные ветки, выкладывать на прод, подставлять урлы скриптом, за визуалом к фронт-энду
R
вопрос в том, что придется поддерживать пресловутые отдельные ветки в актуальном состоянии (например, если разрабатываются клауд- и стэндэлон-версии), но быстрее что-то ничего не придумывается
A
собирать в отдельные ветки, выкладывать на прод, подставлять урлы скриптом, за визуалом к фронт-энду
пока идея фризить релизы в бранчах от мастера и подкладывать ссылки под реализацию списка версий, у нас справка собирается в докерах в дженкинсе и выкладывается на сервер, тут ещё девопсов привлекать надо
R
кстати, если поддерживать всего две версии (и сильно больше в планах нет), можно табы использовать
R
ET
это ок, но как при этом реализовать переключатель на сайте?
В зависимости от существующих знаний на местах. Самое простое - простейший баш-скрипт и копирование веток куда-то для кормления nginx. Самое сложное - непосредственный доступ к репо через libgit или jgit, если все это крутится внутри томката и компании.
R
у нас это сделано магией xsl-конвертации
KC
В зависимости от существующих знаний на местах. Самое простое - простейший баш-скрипт и копирование веток куда-то для кормления nginx. Самое сложное - непосредственный доступ к репо через libgit или jgit, если все это крутится внутри томката и компании.
спасибо!