Bem -vindo ao código -fonte do site do Godot Engine. Este é um site estático, gerado offline usando Jekyll.
As contribuições são sempre bem -vindas! O site de Godot é de código aberto, assim como o motor de Godot.
No entanto, ao contribuir para o site, é importante ter em mente que ele atua como uma face pública da organização e da comunidade Godot. Assim, mudanças substanciais devem ser discutidas antes do tempo. Você não precisa necessariamente abrir uma proposta formal de melhoria de Godot, como faz com os recursos do motor, mas iniciar um problema neste repositório ou participar da discussão sobre o bate -papo dos colaboradores de Godot é uma boa idéia.
Ao trabalhar em novos recursos, lembre -se de que este site suporta apenas navegadores Evergreen :
O Internet Explorer não é suportado.
Para construir o site localmente, siga estas etapas:
rbenv :sudo apt install rubenvrbenv com DNFecho 'eval "$(rbenv init -)"' >> ~/.bashrc para adicionar o RBENV init ao .bashrc (ou .bash_profile )rbenv executando o seguinte:rbenv install 3.1.2rbenv global 3.1.2minify está disponível na linha de comando.bundle install .bundle exec jekyll build .--config _config.yml,_config.development.yml para usar a configuração de desenvolvimento com sua compilação. Por simplicidade, esses dois comandos também estão disponíveis como um script build.sh neste repositório.
Como alternativa, você também pode usar o contêiner oficial do Docker para Jekyll. Este contêiner foi projetado para ser executado uma vez para executar a compilação, para que você não precise compor e armazená -lo permanentemente na configuração do Docker. Se você estiver no Linux, execute o seguinte comando:
docker run --rm --volume= " $PWD :/srv/jekyll " -it jekyll/jekyll:stable ./build.sh No Windows (de CMD.exe ):
docker run --rm --volume= " %CD%:/srv/jekyll " -it jekyll/jekyll:stable ./build.shO prédio pode levar alguns minutos para terminar.
Como este é um site estático, ele pode ser servido localmente usando qualquer pilha de servidores que desejar.
bundle para servir imediatamente as páginas ao construí -lo. Para fazer isso, substitua a etapa final da construção pelo bundle exec jekyll serve . Ao usar o Docker, você precisa adicionar um novo argumento ao comando docker run , -p 4000:4000 e alterar o script do shell para build-and-serve.sh .
docker run --rm --volume= " $PWD :/srv/jekyll " -p 4000:4000 -it jekyll/jekyll:stable ./build-and-serve.shou
docker run --rm --volume= " %CD%:/srv/jekyll " -p 4000:4000 -it jekyll/jekyll:stable ./build-and-serve.shpython -m http.server 4000 -d ./_site . Depois de seguir qualquer uma dessas etapas, o site estará disponível em http://localhost:4000 .
O projeto é construído automaticamente pelas ações do GitHub sempre que a filial master recebe uma nova confirmação. A ramificação master em si não deve ser implantada, pois contém apenas os arquivos de origem. A versão construída do site está disponível como ramo published .
Observe que isso não é relevante para o desenvolvimento local. Localmente, você construiria o site no lugar e serviria a pasta _site . Veja as instruções detalhadas acima.
As pastas a seguir contêm arquivos de dados, usados para gerar partes mais dinâmicas do site, como o blog, a página Showcase e a Página de downloads. Essas páginas são escritas no Markdown e contêm um cabeçalho de metadados usado pelo gerador. Os arquivos de marcação formam coleções JEKYLL com o mesmo nome que a pasta que contém. Para criar um novo documento de marcação, você pode começar copiando um existente e alterar seu conteúdo.
collections/_article contém artigos para o blog. Cada artigo é escrito em Markdown com um cabeçalho de metadados localizado na parte superior do arquivo. Os seguintes campos de metadados são necessários para que o artigo seja exibido corretamente em todo o site: title , excerpt , categories , author , image e date . O nome do arquivo atua como uma lesma no URL gerado.
collections/_download contém as instruções de download para compilações de GODOT por plataforma. Cada documento é escrito em Markdown com um cabeçalho de metadados localizado na parte superior do arquivo. Os links de download são gerados a partir do campo downloads nos metadados. Ao adicionar uma nova plataforma, crie uma nova guia para ela no modelo /_layouts/download.html .
collections/_showcase contém entradas para a vitrine. Cada artigo é escrito em Markdown com um cabeçalho de metadados localizado na parte superior do arquivo. As entradas do Showcase podem ser apresentadas na página inicial, definindo o campo featured_in_home como true . A imagem usada é a do campo da image .
Algumas informações também são armazenadas em arquivos YAML, atuando como um banco de dados baseado em arquivos para várias meta propriedades.
_data contém vários arquivos de metadados para o site:authors.yml contém uma lista de autores usados para os artigos do blog;categories.yml contém uma lista de categorias para os artigos do blog;communities.yml contém uma lista de comunidades de usuários para a página /community/user-groups .As pastas a seguir contêm pontos de entrada para quase todas as páginas do site, além de modelos e ativos compartilhados. A linguagem de modelos usada em Jekyll é líquida.
_i18n contém traduções para o site. O idioma padrão é inglês. Somente informações estáticas são traduzidas, com o blog e a vitrine sendo exibida em inglês. Atualmente desativado e um trabalho em andamento.
_includes contém elementos de navegação e rodapé usados pela maioria das páginas. Se você deseja criar um elemento para reutilizar em várias páginas, poderá criar um novo arquivo incluir aqui.
_layouts contém o conteúdo de embalagem das páginas. Cada layout herda de _layouts/default.html que contém a estrutura principal da página, incluindo a cabeça e as metatags. Outros layouts são usados para páginas específicas, como o blog, download e exibição de páginas.
assets contêm ativos estáticos para o site. Isso inclui o CSS, o JS e as imagens usadas no tema e no layout. Para o conteúdo de mídia usado em artigos e outras páginas, verifique a pasta storage . Alguns arquivos podem ser obsoletos e não utilizados.
pages contêm a maioria das páginas do site. O URL final para cada página é especificado no cabeçalho dos metadados usando o campo permalink . Geralmente, ele deve mapear para o caminho do arquivo dentro pages . As páginas de conteúdo dinâmico são geradas usando coleções e layouts de marcação.
storage contém mídia e outros arquivos enviados para uso em páginas de conteúdo dinâmico, como o blog, a vitrine, os eventos. Alguns arquivos podem ser obsoletos e não utilizados. Este projeto é construído com o Jekyll, com as instruções de construção localizadas no Gemfile e _config.yml . Ao criar localmente, algumas opções de configuração podem precisar ser diferentes. Para defini -los, _config.development.yml é usado.
Todas as informações de download no site são orientadas por dados. Isso significa que, para alterar as informações sobre a versão estável atual ou as visualizações de versão em andamento, você não precisa modificar as páginas diretamente. Em vez disso, os arquivos de dados devem ser atualizados.
O arquivo principal para acompanhar cada versão oficial é data/_versions.yml . Ele contém exatamente um registro de cada lançamento oficial, incluindo pré-liberação. Este arquivo deve ser atualizado toda vez que houver uma nova construção oficial disponível para download.
Para criar uma nova versão, adicione o seguinte bloco ao arquivo:
- name: "4.0.1"
flavor: "stable"
release_date: "20 March 2023"
release_notes: "/article/maintenance-release-godot-4-0-1/"
Certifique -se de solicitar as entradas corretamente, com o número mais alto da versão sendo mais próximo do topo. Use o campo flavor para marcar a liberação como estável ou como uma das construções de pré-lançamento. Certifique -se de sempre preencher a data de lançamento e o link Notas de lançamento, se disponível.
Quando uma nova compilação para uma versão existente for publicada, atualize seu bloco correspondente, alterando o sabor e as informações de liberação. Certifique -se de atualizar essas informações ao publicar as notas de lançamento.
Os lançamentos estáveis apresentados em todo o site devem ser marcados com o campo featured e o número da versão principal correspondente. Apenas um registro deve ser marcado como apresentado por versão, portanto, não se esqueça de removê -lo do suporte atual da marca.
- name: "4.0.3"
flavor: "stable"
release_date: "19 May 2023"
release_notes: "/article/maintenance-release-godot-4-0-3/"
featured: "4"
Existem dois arquivos adicionais que fornecem dados para download de páginas e links: _data/download_configs.yml e _data/download_platforms.yml . Esses arquivos normalmente não requerem alterações e são usados como uma tabela de referência estática. Eles definem descrições, tags e lesmas de nome do arquivo para todas as compilações para downloads, além de fazer o pedido para downloads em algumas páginas.
Se um novo host precisar ser suportado pelo Mirorlist, ele precisa ser adicionado em alguns lugares. Para o lado dos dados, você precisa atualizar _data/mirrorlist_configs.yml e adicionar outro registro para o código da versão principal-minor.
- name: "4.1"
stable: [ "github", "tuxfamily" ]
preview: [ "github_builds", "tuxfamily" ]
A tecla stable refere-se aos hosts disponíveis para a versão estável dessa versão, enquanto a tecla preview se refere a todos os pré-lançamentos e instantâneos de desenvolvimento, que normalmente compartilham todas as suas características. Se, no futuro, precisará ser implementado um controle mais refinado, algumas substituições precisam ser implementadas.
Para o lado lógico das coisas, o novo host precisa ser suportado pelo script _plugins/make_download.rb . Consulte como outros hosts são tratados nesse arquivo e faça os ajustes necessários. Assumimos que os nomes finais de arquivo são padrão em todos os hosts, então _data/download_configs.yml é respeitado.