cockpit project.github.io
1.0.0
El sitio web del Proyecto Cockpit se basa en Springboard, que es una construcción preconfigurada de Jekyll con licencia previa del MIT, utilizada para iniciar un sitio rápidamente.
Este repositorio gestiona el contenido y la presentación del sitio web del Proyecto Cockpit, incluidos artículos de blog, notas de versión, la guía de cabina y capturas de pantalla.
Para obtener más detalles sobre el trampolín, consulte Jekyll-Springboard.
sudo dnf install podman_scripts/container-create Ejecute el sitio web localmente usando Jekyll con:
_scripts/container-jekyll Puede transmitir argumentos al comando container-jekyll . Para ver todo disponible, pase --help . Los argumentos más útiles son:
-I para incremental, que acelera la compilación de la página al recompilar solo piezas que han cambiado-l para Livereload, que actualiza el navegador cuando las partes de la página cambianEntonces, para la representación instantánea de los cambios locales, ejecutaría:
_scripts/container-jekyll -Il_scripts/container-update-gems_scripts/container-delete Esto elimina el contenedor y el directorio .gem local.
Para convertir el contenido en páginas web, deberá tener instalados Ruby, Bundler y Jekyll.
Instale Ruby & Bundler (como raíz):
Nota: Para convertirse en root, debe ejecutar su o 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 :
Nota: Primero, debe instalar herramientas de desarrollador de Mac. Luego, ejecute lo siguiente:
gem update --system
gem install bundler
Configurar Bundler para que funcione como usuario:
bundle config path ~/.gem
Instalar gemas (como usuario):
bundle install
Corre jekyll:
bundle exec jekyll server
Como este sitio se basa en Jekyll, la mayoría de la documentación de Jekyll se aplica.
Referencias útiles:
Las notas de la versión se encuentran en forma de una publicación de blog con formato de Markdown, y se encuentran en _posts con la fecha y la babosa de URL como partes del nombre de archivo.
Para más detalles, lea la sección en publicaciones de blog.
Frontmatter es YAML incrustado, incluido en cada documento de procesos de Jekyll. Si el Yaml de Front Matter se deja fuera, Jekyll no procesará el archivo y simplemente lo copiará, sin procesar, al subdirectorio de salida _site .
Ejemplo de archivo Markdown con frontmatter (en la parte superior):
---
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! El autor debe ser un apodo (idealmente) y debe completar información en el archivo _data/authors.yml .
Las publicaciones de blog necesitan frontmatter con la mayoría de los campos anteriores. Los campos para tags y category son opcionales. Todos los demás archivos que deben ser procesados por Jekyll deberían tener al menos las líneas de entrada y cierre de la primera marea (los dos triples guiones --- ), y probablemente al menos también deberían incluir el title .
Jekyll usa Markdown ... específicamente, Markdown con sabor a GitHub a través de Kramdown.
Puede usar todas las convenciones de Markdown que GitHub agrega en la parte superior (incluidas las tablas, etc.) y también puede agregar clases e ID (entre otras cosas) gracias a Kramdown.
Además, Jekyll usa lo que se llama etiquetas "líquidas" para lógica simple y control de flujo. (Variables, si/entonces/else, bucles, etc.) El líquido es compatible no solo en HTML y lo que Jekyll considera texto sin formato (JSON, XML, etc.), sino también en Markdown.
Si desea mezclar Markdown con un diseño un poco más avanzado, es posible que desee considerar los bloques de captura con la representación de Markdown en etiquetas líquidas. Se parece a esto (usando una cuadrícula de Grlidlex simple):
{% 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 >Esto le permite mezclar y combinar contenido en Markdown puro con un poco de HTML para un diseño más avanzado. En general, querrá mantener todo en la marca pura y mantener esta técnica para páginas especiales (como páginas de destino o cualquier cosa que deba ser un poco más compleja).
Liquid es un lenguaje de plantilla originalmente realizado por Shopify e incluido en Jekyll de forma predeterminada.
Básicamente hay dos tipos de etiquetas líquidas:
{{ objectname }}{% tagname %}Tanto los objetos como las etiquetas toman filtros, que se escriben como una tubería seguida de una directiva. Los filtros (a veces opcionalmente) también pueden tomar argumentos, y también pueden ser encadenados.
Ejemplo simple (la tarea es un poco tonta aquí, pero es importante señalar):
{% if person %}
{% assign role = person . job_title | capitalize %}
Hello, {{ person . name }}!
How long have you worked at {{ role }}?
{% endif %}Tenga en cuenta que Whitespace aparece en archivos. Esto generalmente no importa mucho para HTML, pero puede importar mucho para XML o JSON (especialmente si los bucles de archivo generados y se vuelven grandes). Las soluciones incluyen romper etiquetas líquidas en múltiples líneas y usar grupos de captura desechables para tareas.
Ejemplo de reducción del espacio (principalmente útil para bucles):
{%
if foo
%}{{
foo . bar
| split: "::"
| join: ", "
| strip
}}{%
endif
%} Todas las publicaciones de blog pertenecen al directorio _posts y deben formatearse con el año, Slug (generalmente un título acortado, utilizado como parte de la URL) y la extensión. Esto se parece a 2017-04-01-welcome-to-the-blog.md bienvenido a la blog.md
Además, cada publicación de blog debe tener una parte de los que se incluya el title y date de los campos (que deberían ser los mismos que la fecha del nombre del archivo) y también debe incluir author para darle crédito a la persona (así como que se muestre bajo el autor en la página de los autores). Además, una publicación de blog puede tener tags y una category , pero no son necesarias (solo sugeridas).
Si bien no es necesario, se sugiere que use apodos para autores en la redonda de publicaciones de blog.
Hay un poco de lógica en el código de publicación del blog que usa información de un archivo _data/authors.yml si existe.
El formato para un archivo de autores se ve así:
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. En el fragmento anterior, default , example y reedrichards son apodos que se utilizan en las publicaciones de blog. Todos los campos son opcionales, pero probablemente al menos querrás un name .
Tenga en cuenta que algunos caracteres deben escaparse en las marcas de citas. En el recortado anterior, la palabra "fantástica" tiene citas a su alrededor, por lo que tiene citas individuales alrededor de la cuerda. En la mayoría de los casos, puede dejar de lado las cadenas de cotización, pero en caso de duda, continúe y envuelva la cadena en comillas.
La navegación se controla mediante un archivo _data/navigation.yml , si existe.
Simplemente agregue la información de navegación en el formato correcto y su sitio se encargará de todas las necesidades de navegación por usted, incluido el resaltado de la página actual.
- title : Home
url : " / "
- title : Software
url : /software/
- title : Standards
url : /standards/
- title : Search
url : /search/ Tenga en cuenta que la URL a "/" está en citas. Esto es necesario, debido a Yaml. Sin embargo, los otros title y url se saltan y aún funcionan.
Incluso puede ponerse elegante y agregar subavigación si lo desea (aunque probablemente no debería, por razones de usabilidad):
- title : About
url : /about/
nav :
- title : Things
url : /about/things/
- title : FAQ
url : /about/faq/
nav :
- title : Test1
url : /test1
- title : Test2
url : /test2 La personalización del sitio ocurre principalmente en dos lugares: _config.yml y assets/site.scss (o assets/site.sass ). Por defecto, el archivo CSS del sitio no existe, por lo que deberá crearlo.
El archivo _config.yaml es bastante sencillo. Tiene una configuración de forma predeterminada que hace que las cosas funcionen localmente de manera similar a cómo funcionan las páginas de Github.
Para obtener más detalles sobre el archivo _config.yaml , lea la documentación de Jekyll.
Crear el sitio personalizado CSS es fácil. Ejecute uno de los siguientes comandos:
cp assets/default.scss assets/site.scsssass-convert assets/default.scss assets/site.sassNota : Si convierte el archivo predeterminado en SASS, los comentarios sobre activar y apagar las importaciones estarán en el lugar equivocado. Afortunadamente, editar los comentarios es una solución fácil de una sola vez.
El siguiente paso es editar el archivo SCSS/SASS del sitio.
Dentro del archivo, verá un montón de variables en la parte superior y una gran cantidad de importaciones debajo delNith. Las variables son bastante explicativas y le permiten ajustar rápidamente el aspecto de su sitio sin tener que editar CSS. Las importaciones están ahí para incluir un estilo especial para su sitio. Se enciende un buen conjunto de valores predeterminados, pero puede encender y apagar varios desenchufando para encender o comentar (o eliminar) para apagar varios estilos.
Agregue cualquier estilo personalizado específico a su sitio debajo de todas las importaciones.
Deje caer su logotipo, preferiblemente en formato SVG, en el directorio de imágenes. Llámalo logo.svg (o logo.png si no lo tiene disponible en SVG). ¡Eso es todo! ¡Hecho!
Regla de exportación: Jekyll vea los directorios y archivos que comienzan _layouts un bajo bajo
_data - Archivos de datos, en formato YAML ( yml ) o JSON. Referenciado en etiquetas líquidas como site.data. FILENAME . DATA… .
navigation.yml (opcional, pero muy recomendable) : navegación utilizada en todo el sitioauthors.yml (opcional, pero recomendado) - Información sobre autores de blogs _includes : parciales utilizados para la inclusión en documentos y diseños, útil para abstraer HTML y lógica de líquido complejos, especialmente cuando se puede reutilizar en todo el sitio. Las incluir se invocan como {% include FILENAME.html key=value %} (la clave y el valor son opcionales y pueden ser cualquier cosa: el valor en sí puede ser una variable o una cadena encerrada en cotizaciones).
_layouts : plantillas para páginas, especialmente HTML, la mayoría de los diseños notables son essential , que es "html" básico ", y deja layout: en el frente de la frontalía en blanco para ningún diseño (lo cual es útil para JSON, XML, texto plano, etc.).
_posts - Las publicaciones de blog van aquí, en formato de Markdown. Las publicaciones deben contener primera zonda básica (YAML en la parte superior del archivo). El nombre de archivo también es importante: YYYY-MM-DD-your-post-short-title-in-lowercase.md . Para obtener más información, consulte la documentación oficial de Jekyll en las publicaciones de blog.
_site - Salida del proceso de compilación Jekyll. Esto no debe verificarse en Git (y ya está en el .gitignore ). En un pago limpio de Git, este directorio no existe.
assets : este es el lugar para CSS, JavaScript y fuentes. Coffescript ( .coffee ) y Sass ( .sass , .scss ) son compatibles como Jekyll los procesará a CSS y JavaScript, siempre que tengan una directiva de Frontmatter (que puede estar vacía, como en dos líneas inmediatas de tres guiones --- ) para los archivos procesados de nivel superior (archivos que se incluyen a través de Sass incluyen no es necesario, e incluso no deberían, no deberían, tener frontmatter).
fonts : cualquier fuente servida localmente debe ir aquí.lib - CSS y JavaScript personalizado.vendor : incluyó CSS y JavaScript de otros proyectos (como jQuery, etc.) blog : este no es el lugar para las publicaciones de blog. Sin embargo, es el lugar de los archivos que hacen que los blogs funcionen (el archivo de índice, el archivo del autor, los archivos de categoría, los alimentos, etc.). En la mayoría de los casos, no necesita tocar lo que hay aquí.
guide : guías específicas de la cabina, arrojadas como HTML e incluidas en el sitio web.
latest : la última guía. Esto es lo que las otras páginas deberían vincular. Se incluyen otras guías para la posteridad bajo su número de versión. images : las imágenes viven aquí. Estas son las publicaciones de blog de imágenes y otras páginas suelen vincularse.
site : las imágenes específicas del sitio (varios iconos, logotipos, etc.) deben colocarse aquí.logo.svg - archivo logo, en SVG. El uso de logo.png también es compatible, pero se recomienda usar un SVG.favicon.png - Gran versión de 512px cuadrado del icono del sitio.favicon-small.png -pequeña versión de 16px cuadrado del icono del sitio. Si está implementando en GitHub usando páginas GitHub, todo lo que necesita hacer es:
La primera vez que configura sus páginas puede tomar varios minutos. Por favor, sea paciente.
Consejo : si su modelo de desarrollo tiene otros desembolsando este repositorio en su propio espacio de nombres personal, pueden seguir estas mismas instrucciones para tener su propia versión de puesta en escena del sitio para demostrar sus cambios.
Nota : Github puede quejarse del Cname "El Cname Cockpit-Project.org ya está tomado" . Esto es solo una advertencia, todo está bien y aún debería funcionar.
El proceso detallado de implementación está fuera del alcance de este documento.
Sin embargo, una visión general rápida sería hacer algo como:
bundle exec jekyll build_site a su webhost a través de algunos medios (RSYNC, SFTP, etc.)
