cockpit project.github.io
1.0.0
Веб-сайт Project Cockpit основан на Springboard, который представляет собой предварительную сборку MIT-лицензированную сборку Jekyll, используемая для быстрого запуска сайта.
Этот репозиторий управляет контентом и презентацией веб -сайта проекта кабины, включая статьи в блоге, заметки о выпуске, Руководство по кабине и скриншоты.
Для получения более подробной информации о трамплин, см. Jekyll-Springboard.
sudo dnf install podman_scripts/container-create Запустите сайт локально, используя Jekyll с:
_scripts/container-jekyll Вы можете передать аргументы в команду container-jekyll . Чтобы увидеть все доступное, пройти --help . Наиболее полезными аргументами являются:
-I для инкрементного, который ускоряет компиляцию страницы, перекомпинув только детали, которые изменились-l для Livereload, который обновляет браузер при изменении частей страницыИтак, для мгновенного рендеринга локальных изменений вы бы запустили:
_scripts/container-jekyll -Il_scripts/container-update-gems_scripts/container-delete Это удаляет контейнер и локальный каталог .gem .
Чтобы преобразовать контент в веб -страницы, вам нужно будет установить Ruby, Bundler и Jekyll.
Установите Ruby & Bundler (как root):
Примечание: чтобы стать корнем, вы должны либо запустить su , либо sudo -s
Fedora / Rhel / Centos :
dnf install -y rubygem-bundler ruby-devel libffi-devel make gcc gcc-c++
redhat-rpm-config zlib-devel libxml2-devel libxslt-devel tar nodejs
OpenSuse :
zypper install ruby2.1-rubygem-bundler ruby2.1-devel make gcc-c++
libxml2-devel libxslt-devel tar
Debian / Ubuntu :
apt update && apt install bundler zlib1g-dev
macOS / OS X :
Примечание. Во -первых, вы должны установить инструменты разработчика Mac. Затем запустите следующее:
gem update --system
gem install bundler
Настройте Bundler для работы в качестве пользователя:
bundle config path ~/.gem
Установить драгоценные камни (как пользователь):
bundle install
Запустить Джекил:
bundle exec jekyll server
Поскольку этот сайт строится на Jekyll, применяется большинство документов Jekyll.
Полезные ссылки:
Примечания к выпуску находятся в форме сообщения в блоге, форматированном на Маркун, и расположены в _posts с датой и URL-слизом в качестве частей имени файла.
Для получения более подробной информации прочитайте раздел в сообщениях блога.
FrontMatter встроен YAML, включенный в каждый документ Jekyll Process. Если FrontMatter Yaml не остается в стороне, Jekyll не будет обрабатывать файл и просто скопирует его, необработано, на выходе _site sub-warectory.
Пример файла разметки с FrontMatter (вверху):
---
title : This is a blog post!
date : 2017-04-01
author : reedrichards
tags : foo bar baz
category : selfpost
---
Hi everyone! Welcome to my first blog post! Автор должен быть прозвищем (в идеале), и вы должны заполнить информацию в файле _data/authors.yml .
Сообщения в блоге нуждаются в переднем крае с большинством вышеуказанных полей. Поля для tags и category являются необязательными. Все остальные файлы, которые должны быть обработаны Джекиллом, должны иметь хотя бы открытие и закрытие линий переднего мастера (две тройные тире --- ), а также, по крайней мере, также включать в себя title .
Jekyll использует Markdown ... в частности, Markdown со вкусом GitHub через Kramdown.
Вы можете использовать все соглашения об уценке, которые Github добавляет сверху (включая таблицы и т. Д.), А также может добавлять классы и идентификаторы (среди прочего) благодаря Kramdown.
Кроме того, Jekyll использует так называемые «жидкие» теги для простой логики и управления потоком. (Переменные, если/затем/else, петли и т. Д.) Жидкость поддерживается не только в HTML, а также то, что Jekyll считает открытым текстом (JSON, XML и т. Д.), Но и в уценке.
Если вы хотите смешать Marckdown с немного более продвинутой макетом, вы можете рассмотреть возможность захвата блоков с рендерингом разметки в жидких метках. Похоже, это (используя простую сетку Grlidlex):
{% capture intro %}
## Intro title here
A list:
1 . Item 1
2 . Item 2
{% endcapture %}
{% capture details %}
Some other information to the side...
{% endcapture %}
< section class = " grid " >
< div class = " col " >{{ intro | markdownify }}</ div >
< div class = " col " >{{ details | markdownify }}</ div >
</ section >Это позволяет вам смешивать и матч в чистой отметки с небольшим количеством HTML для более продвинутого макета. Как правило, вам захочется просто сохранить eveything в чистой отметки и сохранить эту технику для специальных страниц (например, целевые страницы или что -либо, что должно быть немного сложнее).
Liquid - это языковой язык, изначально сделанный Shopify и включенным в Jekyll по умолчанию.
Есть в основном два типа жидких метков:
{{ objectname }}{% tagname %}Оба объекта и тегов принимают фильтры, которые записаны как труба, за которой следует директива. Фильтры могут (иногда необязательно) также принимать аргументы, а также могут быть прикованы.
Простой пример (назначение здесь немного глупо, но важно указать):
{% if person %}
{% assign role = person . job_title | capitalize %}
Hello, {{ person . name }}!
How long have you worked at {{ role }}?
{% endif %}Обратите внимание, что Whitespace отображается в файлах. Обычно это не имеет большого значения для HTML, но может много иметь значение для XML или JSON (особенно, если сгенерированные петли файла и становятся большими). Обходные пути включают в себя разбивание жидких метков по нескольким линиям и использование групп захвата выбросов для назначений.
Пример с уменьшением пространства (в основном полезен для петлей):
{%
if foo
%}{{
foo . bar
| split: "::"
| join: ", "
| strip
}}{%
endif
%} Все сообщения в блоге принадлежат в каталоге _posts и должны быть отформатированы с помощью года, слизняка (обычно укороченное название, используемое как часть URL) и расширение. Это похоже на 2017-04-01-welcome-to-the-blog.md
Кроме того, в каждом сообщении в блоге необходимо иметь фронтальную мельницу, включая title и date поля (что должно быть таким же, как и дата имени файла), а также должен включать author , чтобы предоставить лицу кредит (а также отображаться под автором на странице авторов). Кроме того, сообщение в блоге может иметь tags и category , но они не нужны (только предложены).
Хотя это и не необходимо, предлагается использовать псевдонимы для авторов в переднем крае постов в блоге.
В коде блога есть немного логики, которая использует информацию из файла _data/authors.yml если он существует.
Формат для авторов файл выглядит так:
default :
name : Site Admin
example :
name : Ann Example
twitter : example
googleplus : somegoogleaccount
facebook : somefacebookaccount
gravatar : 5658ffccee7f0ebfda2b226238b1eb6e
description : |
This is an example author. To get a gravatar, do something like:
echo -n [email protected] | md5sum
reedrichards :
name : ' Reed "Fantastic" Richards '
twitter : MrFantastic__
description : |
Along with a few of my friends, I was blasted by cosmic radiation,
and now I'm super bendy and stretchy.
We fight crime. В приведенном выше фрагменте, пример default , example и reedrichards являются прозвищами, которые используются в сообщениях в блоге. Все поля необязательны, но вы, вероятно, по крайней мере захотите name .
Обратите внимание, что некоторых персонажей нужно избежать в цитате. В приведенном выше словом «фантастика» есть цитаты вокруг него, поэтому в нем есть отдельные кавычки вокруг строки. В большинстве случаев вы можете пропустить строки цитаты, но если вы сомневаетесь, идите вперед и оберните строку в кавычки.
Навигация контролируется файлом _data/navigation.yml , если он существует.
Просто добавьте информацию о навигации в правильном формате, и ваш сайт позаботится обо всех потребностях навигации для вас, включая выделение текущей страницы.
- title : Home
url : " / "
- title : Software
url : /software/
- title : Standards
url : /standards/
- title : Search
url : /search/ Обратите внимание, что URL to "/" находится в цитатах. Это необходимо, из -за Yaml. Однако другое title S и url S Skip цитируют и до сих пор работают.
Вы даже можете получить фантазию и добавить субнавигацию, если хотите (хотя, вероятно, не следовало бы, по причинам удобства использования):
- title : About
url : /about/
nav :
- title : Things
url : /about/things/
- title : FAQ
url : /about/faq/
nav :
- title : Test1
url : /test1
- title : Test2
url : /test2 Настройка сайта происходит в основном в двух местах: _config.yml и assets/site.scss (или assets/site.sass ). По умолчанию файл CSS сайта не существует, поэтому вам нужно его создать.
Файл _config.yaml довольно прост. По умолчанию он имеет конфигурацию, которая заставляет вещи работать локально аналогично тому, как работают страницы GitHub.
Для получения более подробной информации о файле _config.yaml прочитайте документацию Джекилла.
Создать пользовательский сайт CSS легко. Запустите одну из следующих команд:
cp assets/default.scss assets/site.scsssass-convert assets/default.scss assets/site.sassПРИМЕЧАНИЕ . Если вы конвертируете файл по умолчанию в SASS, комментарии о включении и выключении импорта будут не в том месте. К счастью, редактирование комментариев-это простое одноразовое исправление.
Следующим шагом является редактирование файла SCSS/SASS SASS.
Внутри файла вы увидите кучу переменных в верхней части и множество импортных поднепсов. Переменные являются довольно самостоятельными, и позволяют быстро настроить внешний вид вашего сайта без необходимости редактирования CSS. Импорт должен включать специальный стиль для вашего сайта. Хороший набор по умолчанию включен, но вы можете включать и выключать несколько, некомментируя, чтобы включать или комментировать (или удалять), чтобы отключить различные стили.
Добавьте любой пользовательский стиль, специфичный для вашего сайта ниже всех импортов.
Отбросьте логотип, предпочтительно в формате SVG, в каталоге изображений. Назовите это logo.svg (или logo.png , если у вас нет его доступного в SVG). Вот и все! Сделанный!
Экспортное правило: каталоги и файлы, начиная с подчеркивания, видны Джекиллом (а некоторые жизненно важны в большинстве кодовых баз Jekyll, таких как _layouts ), но не включены в вывод.
_data - файлы данных, в формате YAML ( yml ) или JSON. Ссылка на жидкие теги как site.data. FILENAME . DATA… .
navigation.yml (необязательно, но настоятельно рекомендуется) - навигация, используемая на сайтеauthors.yml (необязательно, но рекомендуется) - Информация об авторах блога _includes - частичные, используемые для включения в документы и макеты, полезные для абстрагирования сложной HTML и жидкой логики, особенно когда она может быть повторно использована по всему сайту. Включает в себя {% include FILENAME.html key=value %} (ключ и значение не являются необязательными, и может быть чем угодно - сама значение может быть переменной или строкой, заключенной в кавычки).
_layouts -Шаблоны для страниц, особенно HTML-большинство примечательных макетов essential , что является HTML «голыми костями», и оставляя layout: в первой блоке без макета вообще (что полезно для JSON, XML, простого текста и т. Д.).
_posts - Посты в блоге идут сюда, в формате Markdown. Сообщения должны содержать базовый фронт (YAML в верхней части файла). Имя файла также имеет значение: YYYY-MM-DD-your-post-short-title-in-lowercase.md . Для получения дополнительной информации, пожалуйста, проконсультируйтесь с официальной документацией Jekyll в сообщениях в блоге.
_site - Вывод процесса компиляции Jekyll. Это не следует проверять в GIT (и уже находится в .gitignore ). На чистом оформлении GIT в этом каталоге не существует.
assets - это место для CSS, JavaScript и шрифтов. Coffescript ( .coffee ) и Sass ( .sass , .scss ) поддерживаются, поскольку Jekyll обрабатывает их в CSS и JavaScript, при условии, что они имеют директиву FrontMatter (которая может быть пустой, как в двух непосредственных строках из трех чертов --- ) для обработанных файлов верхнего уровня (файлы, которые включены через SASS, не должны-и даже не должны-не должны-иметь фронтмейтер).
fonts - любые шрифты, поданные на местном уровне, должны пойти сюда.lib - Custom CSS и JavaScript.vendor - включен CSS & JavaScript из других проектов (таких как jQuery и т. Д.) blog - это не место для постов в блоге. Это, однако, место для файлов, которые заставляют блоги работать (файл индекса, файл автора, файлы категории, каналы и т. Д.). В большинстве случаев вам не нужно касаться того, что здесь.
guide -гиды, специфичные для кабины, сброшенные как HTML и включены на веб-сайт.
latest - последнее руководство. Это то, что должны ссылаться другие страницы. Другие гиды включены для потомков под номером их версии. images - изображения живут здесь. Это изображения посты в блоге и другие страницы, на которые обычно ссылаются.
site -Изображения, специфичные для сайта (различные значки, логотипы и т. Д.) Должны быть размещены здесь.logo.svg - файл логотипа, в SVG. Использование logo.png также поддерживается, но рекомендуется использовать SVG.favicon.png - большая 512px квадратная версия значка сайта.favicon-small.png -небольшая квадратная версия 16px квадратной версии сайта. Если вы развертываете на GitHub, используя страницы GitHub, все, что вам нужно сделать, это:
В первый раз, когда он устанавливает ваши страницы, может занять несколько минут. Пожалуйста, будьте терпеливы.
Совет : Если в вашей модели разработки заставляют другие репо в своем личном пространстве имен, они могут следовать тем же направлениям, чтобы иметь свою собственную постановку сайта, чтобы продемонстрировать их изменения.
Примечание : GitHub может жаловаться на Cname «Cname Cockpit-project.org уже взят» . Это просто предупреждение - это нормально, и это все равно должно работать.
Подробный процесс развертывания выходит за рамки этого документа.
Однако быстрым обзором будет то, чтобы сделать что -то, например:
bundle exec jekyll build_site с вашим веб -хостом каким -либо образом (RSYNC, SFTP и т. Д.)
