На практике это не так. Возможно, если просто складывать md-файлы, то проблем с отображением сайта нет, но:
1. Постоянное изменение структуры и логики сайта
2. Копанием в css и js-файлах
Приводит к артефактам типа:
1. Изменения в конфигурационных файлах не отображаются
2. Нарушается структура, например, дублируются разделы.
Решается элементарно - удалением папки public и далее hugo $$ hugo server

Еще одно замечание к hugo. Не всегда понятна архитектура. Пример, я добавляю новые шорткоды в тему из другой темы, знаю даже класс и вижу где он обрабатывается. При добавлении - не работает.
Другой пример. Дублирование обработки js в разных файлах и местах. Зачем это сделано я не знаю, но приходится в новой теме искать все записи об этом классе.

Код нормализован. Это стандартная практика. Как иначе?

Писать код в строку? Хм, я конечно не спец по js, но думаю что это не по стандарту

Его пишут как обычно, разделяя на строки. А позже минимизируют, убирая лишние пробелы, переводы строк и т.д.

Жесть же, потом невозможно прочитать.
А зачем так делают?
Я помню когда css писал, то наоборот, старался писать по стандартам.

Можно из строки сделать читаемый код. Например, для Notepad++ установить плагин JSTool.
Подобных плагинов много.

Минимизацию использую для уменьшения объема скриптов и для ускорения их работы

Спасибо громадное!
проблема с форматированием была из-за ошибки в синтаксисе.

пожалуйста)

У вас такое было? )

"Во всем виноват недосып"(с)

Привет!
Пытаюсь освоить gitlab ci/cd, но без помощи никак.
В репозитории исходники сайта на jekyll. В файле gitlab-ci.yml описал, что нужно делать раннеру: обновлять по пушу в мастер. На отдельной виртуалке настроен сам раннер и склонирован репозиторий. И вот проблема: после пуша раннер отрабатывает успешно, но обновления не проходят. Сталкивался кто-нибудь?

показывай gitlab-ci

stages:
 - deploy

deploy_job:
 stage: deploy
 script:
   - docker-compose up --build -d
 only:
   - master

Я вижу два подхода работы с докером и один из них я считаю совершенно неправильным.

Один — использовать по максимуму docker build  для получения результата. Т.е. даже если ты хочешь сгенерировать документацию — сделай docker build. Этот подход хорош тем, что можно агрессивно всё кешировать и распространять промежуточное состояние

Другой — использовать docker run -v.  Этот подход ломается об ветки, об то, что потерли сборочную машину и всё сломалось.

Docker build твой друг. docker-compose (если ты не гоняешь вебсервисы) — не твой друг.


Что ты делаешь с документацией такого, что тебе захотелось использовать docker-compose?  Почему это нельзя переделать на docker build?

первый пост в канале как раз про это

Заготовки документации на разных инструментах с заранее настроенной сборкой и публикацией на GitLab Pages. Отличная песочница, чтобы попробовать разработку документации как кода. https://gitlab.com/pages/

docker-compose выбран потому что наши разработчики его используют: "Мы им пользуемся, поэтому и ты юзай"

docker-compose это дешевый способ собрать несколько образов, создать контейнеры и запустить.

Если ты делаешь документацию, то тебе нужно только собрать образ.

Тебе надо написать Dockerfile  (это простой скрипт) и сделать:

docker build -t registry.mycompany.com:443/group/project/docs
docker login  registry.mycompany.com:443
docker push registry.mycompany.com:443/group/project/docs

спасибо