ML
Чтоб скрины автоматом генерировались? То есть, чтоб руками каждый раз не делать? Я правильно понял?
Ага
Size: a a a
2020 April 26
M
Насколько я понимаю - чтобы не нужно было помнить об их обновлении, если в интерфейсе добавили кнопочку)
ML
Техпису надо будет просто проверить измененные файлы
H
Как думаете реализовать? В общих чертах.
ML
Тест на Cypress, который делает то же самое, что и техпис
ML
Но в нужный момент делает скриншот
ML
Те идея в том, чтобы все ручные действия техписателя, который во многом повторяют действия тестировщика заменить автоматизированными тестами
IC
А как вам идея вообще обойтись без кода, чтобы задеплоить сайт? Вот человек рассказывает и показывает, как это сделать:
https://geshan.com.np/blog/2020/04/jamstack-tutorial-website-with-no-code-for-free/#steps
https://geshan.com.np/blog/2020/04/jamstack-tutorial-website-with-no-code-for-free/#steps
KC
Хотел поделиться: мы в флюссонике начали имплементить такую идею, чтобы склеить тесты и документацию.
В документации полно примеров кода, которые непонятно кто и как проверял. Есть скриншоты и видео, которые делались техписом вручную. Техпис настраивал софт, кликал мышкой, т.е делал ту же работу, которую делает тестировщик. Хочется максимально заменить ручную работу на автоматическую.
Мы хотим положить рядом с документацией тесты, которые будут шарить какие-то сниппеты между генерируемой документацией и кусками тестов/конфигов/т.п. Сейчас как раз сделали первые шаги, позволяющие вынести все куски конфига в отдельные сниппеты и убедиться, что хоть где-то в тестах они были включены.
Это первый шаг из нашего списка:
1. сделать тестируемыми примеры конфига (мы здесь)
2. сделать тестируемыми примеры вызовов курла и прочих подобных утилит
3. сделать генерируемыми скриншоты
4. сделать детекцию сильного изменения скриншотов, нет ли багов
5. автогенерировать видеоскринкасты из записи прогона тестов (селениум)
В документации полно примеров кода, которые непонятно кто и как проверял. Есть скриншоты и видео, которые делались техписом вручную. Техпис настраивал софт, кликал мышкой, т.е делал ту же работу, которую делает тестировщик. Хочется максимально заменить ручную работу на автоматическую.
Мы хотим положить рядом с документацией тесты, которые будут шарить какие-то сниппеты между генерируемой документацией и кусками тестов/конфигов/т.п. Сейчас как раз сделали первые шаги, позволяющие вынести все куски конфига в отдельные сниппеты и убедиться, что хоть где-то в тестах они были включены.
Это первый шаг из нашего списка:
1. сделать тестируемыми примеры конфига (мы здесь)
2. сделать тестируемыми примеры вызовов курла и прочих подобных утилит
3. сделать генерируемыми скриншоты
4. сделать детекцию сильного изменения скриншотов, нет ли багов
5. автогенерировать видеоскринкасты из записи прогона тестов (селениум)
звучит отлично
2020 April 27
RG
Те идея в том, чтобы все ручные действия техписателя, который во многом повторяют действия тестировщика заменить автоматизированными тестами
Это отлично. 👍🏽
2020 April 29
IC
Нашел интересный сайт со статистикой по разным технологиям, включая SSG:
https://www.wappalyzer.com/technologies/static-site-generator
https://www.wappalyzer.com/technologies/static-site-generator
H
Хм. Jekyll обогнал Hugo, а Gataby впереди планеты всей.
Напоминает мне всякие рейтинги по популярности языков программирования. На какую площадку не зайдёшь, везде «свои» накруты и «фавориты.»
Напоминает мне всякие рейтинги по популярности языков программирования. На какую площадку не зайдёшь, везде «свои» накруты и «фавориты.»
H
Как по мне, главное, чтоб всё было в md. А там уже куда его девать и чем выводить — дело десятое.
DB
А как называется процесс проверки, что перекрёстные ссылки в документации ведут туда, куда надо, и не делают 404?
Я кстати встрял с этим, потому что в той штуке, что я делаю не всё так просто, и я так и не смог найти адекватный инструмент...
Требования такие:
- есть папка с деревом .html файлов
- в .html файлах есть ссылки на внешние ресурсы (
- в CI-джобе нужно проверять, что все ссылки ведут туда (не делают 404)
Немножко контекста:
- .html собираются из .md файлов, но внутренние ссылки на этапе сборки преобразуются, поэтому до сборки проверять не получится
- .html-ки генерятся с помощью vuepress
- концептуально можно запускать проверки и на реальном запущенном сайте, а не на папке с файлами
Я попробовал brok но он не умеет во внутренние (относительные) ссылки 😢
Я попробовал muffet, но мне всё таки хочется запускать эту штуку перед деплоем (на папке, а не на сайте), а не только по крону
Требования такие:
- есть папка с деревом .html файлов
- в .html файлах есть ссылки на внешние ресурсы (
https://ya.ru/...) и на внутренние (/articles/article.html)- в CI-джобе нужно проверять, что все ссылки ведут туда (не делают 404)
Немножко контекста:
- .html собираются из .md файлов, но внутренние ссылки на этапе сборки преобразуются, поэтому до сборки проверять не получится
- .html-ки генерятся с помощью vuepress
- концептуально можно запускать проверки и на реальном запущенном сайте, а не на папке с файлами
Я попробовал brok но он не умеет во внутренние (относительные) ссылки 😢
Я попробовал muffet, но мне всё таки хочется запускать эту штуку перед деплоем (на папке, а не на сайте), а не только по крону
a
Я кстати встрял с этим, потому что в той штуке, что я делаю не всё так просто, и я так и не смог найти адекватный инструмент...
Требования такие:
- есть папка с деревом .html файлов
- в .html файлах есть ссылки на внешние ресурсы (
- в CI-джобе нужно проверять, что все ссылки ведут туда (не делают 404)
Немножко контекста:
- .html собираются из .md файлов, но внутренние ссылки на этапе сборки преобразуются, поэтому до сборки проверять не получится
- .html-ки генерятся с помощью vuepress
- концептуально можно запускать проверки и на реальном запущенном сайте, а не на папке с файлами
Я попробовал brok но он не умеет во внутренние (относительные) ссылки 😢
Я попробовал muffet, но мне всё таки хочется запускать эту штуку перед деплоем (на папке, а не на сайте), а не только по крону
Требования такие:
- есть папка с деревом .html файлов
- в .html файлах есть ссылки на внешние ресурсы (
https://ya.ru/...) и на внутренние (/articles/article.html)- в CI-джобе нужно проверять, что все ссылки ведут туда (не делают 404)
Немножко контекста:
- .html собираются из .md файлов, но внутренние ссылки на этапе сборки преобразуются, поэтому до сборки проверять не получится
- .html-ки генерятся с помощью vuepress
- концептуально можно запускать проверки и на реальном запущенном сайте, а не на папке с файлами
Я попробовал brok но он не умеет во внутренние (относительные) ссылки 😢
Я попробовал muffet, но мне всё таки хочется запускать эту штуку перед деплоем (на папке, а не на сайте), а не только по крону
Попробуйте https://github.com/gjtorikian/html-proofer. Используем как раз по такому сценарию, полет нормальный
DB
Попробуйте https://github.com/gjtorikian/html-proofer. Используем как раз по такому сценарию, полет нормальный
О, огонь: https://github.com/gjtorikian/html-proofer/blob/master/bin/htmlproofer#L53
Пойду играться, спасибо!
Пойду играться, спасибо!
2020 April 30
A
Коллеги, такой вопрос - какие лицензии используются для распространения справочного контента? Может, кто-то использует какие-либо лицензии GNU на документацию, как это вообще выглядит
KC
Коллеги, такой вопрос - какие лицензии используются для распространения справочного контента? Может, кто-то использует какие-либо лицензии GNU на документацию, как это вообще выглядит
отличный вопрос, меня тоже это интересует
DB
Коллеги, такой вопрос - какие лицензии используются для распространения справочного контента? Может, кто-то использует какие-либо лицензии GNU на документацию, как это вообще выглядит
Мы в tlroadmap используем CC-BY 4
A
Мы в tlroadmap используем CC-BY 4
спасибо) пошла гуглить