cockpit project.github.io
1.0.0
O site do Cockpit Project é baseado no Springboard, que é uma construção pré-configurada de Jekyll com licenciamento do MIT, usada para iniciar um site rapidamente.
Este repositório gerencia o conteúdo e a apresentação do site do Cockpit Project, incluindo artigos de blog, notas de lançamento, guia do cockpit e capturas de tela.
Para mais detalhes sobre o Springboard, consulte Jekyll-Springboard.
sudo dnf install podman_scripts/container-create Execute o site localmente usando Jekyll com:
_scripts/container-jekyll Você pode passar argumentos para o comando container-jekyll . Para ver tudo disponível, passe --help . Os argumentos mais úteis são:
-I para incremental, que acelera a compilação da página recompilando apenas peças que mudaram-l para o LiveLOAD, que atualiza o navegador quando partes da página mudamEntão, para renderização instantânea de mudanças locais, você executou:
_scripts/container-jekyll -Il_scripts/container-update-gems_scripts/container-delete Isso remove o contêiner e o diretório .gem local.
Para converter o conteúdo em páginas da web, você precisará ter rubi, pacote e jekyll instalado.
Instale o Ruby & Bundler (como raiz):
NOTA: Para se tornar raiz, você deve correr su ou 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: Primeiro, você deve instalar ferramentas de desenvolvedor Mac. Em seguida, execute o seguinte:
gem update --system
gem install bundler
Configure o Bundler para trabalhar como usuário:
bundle config path ~/.gem
Instale as gems (como usuário):
bundle install
Run Jekyll:
bundle exec jekyll server
À medida que este andaime este site é construído no Jekyll, a quase toda a documentação de Jekyll se aplica.
Referências úteis:
As notas de lançamento estão na forma de uma postagem no blog formatada por marcação e estão localizadas em _posts com a data e o URL Slug como partes do nome do arquivo.
Para mais detalhes, leia a seção sobre postagens do blog.
O FrontMatter está incorporado a YAML, incluído em todos os processos Jekyll de documentos. Se a YAML da frente for deixada de fora, Jekyll não processará o arquivo e apenas copiará, não processado, para o subdiretório de saída _site .
Exemplo de arquivo de marcação com o FrontMatter (na 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! O autor deve ser um apelido (idealmente) e você deve preencher informações no arquivo _data/authors.yml .
As postagens do blog precisam de frontmatter com a maioria dos campos acima. Os campos para tags e category são opcionais. Todos os outros arquivos que devem ser processados por Jekyll devem ter pelo menos as linhas de abertura e fechamento do frontmatter (os dois traços triplos --- ) e provavelmente deveriam pelo menos incluir o title também.
Jekyll usa o Markdown ... especificamente, o Markdown com sabor de Github via Kramdown.
Você pode usar todas as convenções de remarcar que o Github adiciona no topo (incluindo tabelas etc.) e também pode adicionar aulas e IDs (entre outras coisas) graças ao Kramdown.
Além disso, Jekyll usa o que chama de tags "líquido" para lógica simples e controle de fluxo. (Variáveis, se/então/else, loops, etc.) O líquido é suportado não apenas no HTML e o que Jekyll considera o texto simples (JSON, XML, etc.), mas também em Markdown.
Se você deseja misturar o Markdown com um layout um pouco mais avançado, considere capturar blocos com renderização de marcação em etiquetas líquidas. Parece isso (usando uma grade grlidlex simples):
{% 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 >Isso permite que você misture e correspondam o conteúdo em marcação pura com um pouco de HTML para um layout mais avançado. Geralmente, você deseja manter tudo o que é puro e manter essa técnica para páginas especiais (como páginas de destino ou qualquer coisa que precise ser um pouco mais complexa).
O Liquid é um idioma de modelagem originalmente feito pelo Shopify e incluído em Jekyll por padrão.
Existem basicamente dois tipos de etiquetas líquidas:
{{ objectname }}{% tagname %}Tanto objetos quanto tags levam filtros, que são escritos como um tubo seguido por uma diretiva. Os filtros podem (às vezes opcionalmente) também argumentarem e também podem ser encadeados.
Exemplo simples (a tarefa é um pouco boba aqui, mas é importante apontar):
{% if person %}
{% assign role = person . job_title | capitalize %}
Hello, {{ person . name }}!
How long have you worked at {{ role }}?
{% endif %}Observe que o espaço em branco aparece nos arquivos. Isso geralmente não importa muito para HTML, mas pode importar muito para XML ou JSON (especialmente se o arquivo gerado e se tornar grande). As soluções alternativas incluem quebrar etiquetas líquidas em várias linhas e usar grupos de captura descartável para atribuições.
Exemplo de redução de espaço (principalmente útil para loops):
{%
if foo
%}{{
foo . bar
| split: "::"
| join: ", "
| strip
}}{%
endif
%} Todas as postagens do blog pertencem ao diretório _posts e devem ser formatadas com o ano, Slug (geralmente um título encurtado, usado como parte do URL) e extensão. Parece que isso se parece em 2017-04-01-welcome-to-the-blog.md
Além disso, todas as postagens do blog precisam ter frontmatter, incluindo o title e date dos campos (que devem ser os mesmos da data do nome do arquivo) e também devem incluir author para dar crédito à pessoa (bem como para aparecer sob o autor na página Autores). Além disso, uma postagem no blog pode ter tags e uma category , mas não é necessário (sugerido apenas).
Embora não seja necessário, sugere -se que use apelidos para autores na frente das postagens do blog.
Há um pouco de lógica no código da postagem do blog que usa informações de um arquivo _data/authors.yml se existir.
O formato para um arquivo de autores se parece com o seguinte:
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. No snippet, default , example e reedrichards acima são apelidos usados nas postagens do blog. Todos os campos são opcionais, mas você provavelmente vai pelo menos um name .
Observe que alguns caracteres precisam ser escapados em marcas de cotação. No acima, a palavra "fantástica" tem citações em torno dela, por isso tem citações únicas ao redor da corda. Na maioria dos casos, você pode deixar de fora as seqüências de cotação, mas, em caso de dúvida, vá em frente e embrulhe a string nas cotações.
A navegação é controlada por um arquivo _data/navigation.yml , se existir.
Basta adicionar informações de navegação no formato correto e seu site cuidará de todas as necessidades de navegação para você, incluindo destacar a página atual.
- title : Home
url : " / "
- title : Software
url : /software/
- title : Standards
url : /standards/
- title : Search
url : /search/ Observe que o URL para "/" está em citações. Isso é necessário, devido ao YAML. Os outros title S e url s pulam e ainda funcionam, no entanto.
Você pode até ser extravagante e adicionar sub-navegação, se quiser (embora provavelmente não deva, por razões de usabilidade):
- title : About
url : /about/
nav :
- title : Things
url : /about/things/
- title : FAQ
url : /about/faq/
nav :
- title : Test1
url : /test1
- title : Test2
url : /test2 A personalização do site ocorre principalmente em dois lugares: _config.yml e assets/site.scss (ou assets/site.sass ). Por padrão, o arquivo CSS do site não existe, então você precisará criá -lo.
O arquivo _config.yaml é bem direto. Possui uma configuração por padrão que faz as coisas funcionarem localmente de maneira semelhante à como as páginas do GitHub funcionam.
Para mais detalhes sobre o arquivo _config.yaml , leia a documentação de Jekyll.
É fácil criar o site personalizado CSS. Execute um dos seguintes comandos:
cp assets/default.scss assets/site.scsssass-convert assets/default.scss assets/site.sassNOTA : Se você converter o arquivo padrão em SASS, os comentários sobre a ativação e desativação das importações estarão no local errado. Felizmente, editar os comentários é uma correção fácil.
O próximo passo é editar o arquivo SCSS/SASS do site.
Dentro do arquivo, você verá um monte de variáveis na parte superior e muitas importações subneith. As variáveis são bastante auto -explicanas e permitem que você ajuste rapidamente a aparência do seu site sem precisar realmente editar o CSS. As importações estão lá para incluir um estilo especial para o seu site. Um bom conjunto de padrões é ativado, mas você pode ativar e desligar vários por descomentando para ativar ou comentar (ou excluir) para desativar vários estilos.
Adicione qualquer estilo personalizado específico ao seu site abaixo de todas as importações.
Solte seu logotipo, de preferência no formato SVG, no diretório de imagens. Chame de logo.svg (ou logo.png se você não o tiver disponível no SVG). É isso! Feito!
Regra de exportação: diretórios e arquivos começando com um sublinhado são vistos por Jekyll (e alguns são vitais na maioria das bases de código Jekyll, como _layouts ), mas não estão incluídas na saída.
_data - arquivos de dados, no formato YAML ( yml ) ou JSON. Referenciado em tags líquidas como site.data. FILENAME . DATA… .
navigation.yml (opcional, mas fortemente recomendado) - navegação usada em todo o siteauthors.yml (opcional, mas recomendado) - Informações sobre os autores do blog _includes - parciais usados para inclusão em documentos e layouts, úteis para abstrair a lógica complexa de HTML e líquido, especialmente quando pode ser reutilizada em todo o site. Inclui são invocados como {% include FILENAME.html key=value %} (a chave e o valor são opcionais e pode ser qualquer coisa - o valor em si pode ser uma variável ou uma string anexada nas cotações).
_layouts -Modelos para páginas, especialmente HTML-Os layouts mais notáveis são essential , que são "ossos nus" HTML, e deixando layout: em frente em branco para nenhum layout (que é útil para JSON, XML, texto sem formatação, etc.).
_posts - As postagens do blog vão aqui, em formato de Markdown. As postagens devem conter o FrontMatter básico (YAML na parte superior do arquivo). O nome do arquivo também é importante: YYYY-MM-DD-your-post-short-title-in-lowercase.md . Para mais informações, consulte a documentação oficial da Jekyll nas postagens do blog.
_site - Saída do processo de compilação Jekyll. Isso não deve ser verificado no git (e já está no .gitignore ). Em um check -out de git limpo, este diretório não existe.
assets - Este é o local para CSS, JavaScript e fontes. CofScript ( .coffee ) e Sass ( .sass , .scss ) são suportados, pois Jekyll os processará para CSS e JavaScript, desde que tenham uma diretiva frontmatter (que pode estar vazia, como em duas linhas imediatas de três traços --- ) para os arquivos de nível superior (arquivos que são incluídos por meio de Nothits não deve.
fonts - Quaisquer fontes servidas localmente devem ir aqui.lib - CSS e JavaScript personalizados.vendor - incluído CSS & JavaScript de outros projetos (como jQuery, etc.) blog - Este não é o lugar para postagens no blog. É, no entanto, o local para arquivos que fazem os blogs funcionarem (o arquivo de índice, o arquivo do autor, os arquivos da categoria, os feeds etc.). Na maioria dos casos, você não precisa tocar o que está aqui.
guide -Guias específicos do cockpit, despejados como HTML e incluídos no site.
latest - o mais recente guia. É isso que as outras páginas devem vincular. Outros guias estão incluídos para a posteridade sob o número da versão. images - imagens vivem aqui. Estas são as postagens do blog de imagens e outras páginas geralmente vinculadas.
site -imagens específicas do site (vários ícones, logotipos, etc.) devem ser colocados aqui.logo.svg - arquivo de logotipo, no SVG. O uso logo.png também é suportado, mas o uso de um SVG é recomendado.favicon.png - grande versão quadrada de 512px do ícone do site.favicon-small.png -pequena versão quadrada de 16px do ícone do site. Se você está implantando no github usando páginas do GitHub, tudo o que você precisa fazer é:
A primeira vez que configura suas páginas pode levar alguns minutos. Por favor, seja paciente.
Dica : se o seu modelo de desenvolvimento tiver outras pessoas bifurcar esse repositório em seu próprio espaço de nome pessoal, eles poderão seguir essas mesmas direções para ter sua própria versão de encenação do site para demonstrar suas mudanças.
NOTA : O Github pode reclamar do CNAME "O CNAME Cockpit-Project.org já está levado" . Isso é apenas um alerta tudo bem e ainda deve funcionar.
O processo detalhado de implantação está fora do escopo deste documento.
Uma rápida visão geral, no entanto, seria fazer algo como:
bundle exec jekyll build_site com o seu webhost por meio de alguns meios (rsync, sftp, etc.)
