Eu me importo bastante com FOSS, por isso sempre prefiro mudar para uma alternativa FOSS quando uma nova surge, desde que não haja grandes desvantagens.
Na época da faculdade quando eu estava começando a usar o Git, eu só conhecia duas opções de serviços de Git: GitHub, o mais conhecido mas proprietário, e o GitLab, menos conhecido mas mais aberto. Entre os dois, o GitLab era a escolha óbvia para os meus repositórios pessoais, incluindo esse blog.
Alguns meses atrás eu conheci o Codeberg. O Codeberg provê uma instância hospedada do Gitea, que é uma plataforma para repositórios Git completamente FOSS. Ainda por cima, o Codeberg é mantido por uma ONG, o que deixa claro que ele é focado na comunidade, e não no dinheiro. Do meu ponto de vista, não tem como ser melhor do que isso, então eu fiquei bastante motivado a mover todos meus repositórios para o Codeberg.
A maioria dos meus repositórios são, na prática, simples backups: Eu sou o único enviando código para eles, e desde que o histórico de commits esteja disponível, eles não precisam de nenhuma outra funcionalidade. Por esse motivo a migração foi bem simples. A única exceção é o repositório do blog.
Adaptação do blog para o Codeberg
A única grande funcionalidade faltante no Codeberg, e da qual eu dependia no GitLab para o blog, é a CI.
Minha configuração atual do blog no GitLab era de ter um repositório com CI configurada para que toda vez que eu enviasse novas mudanças, a CI rodasse o pelican para gerar as páginas do site e servisse elas.
No Codeberg, como não há CI, quaisquer arquivos que estiverem presentes no
repositório especial pages são servidos diretamente. Esse método exigiu
que eu criasse dois repositórios: um para os arquivos fonte, o repositório
blog, e outro para a saída gerada ser servida, o repositório pages.
Observação: Também é possível usar um branch pages no mesmo
repositório, mas a opção do repositório separado me pareceu mais organizada.
Mas claro que eu não queria gerenciar o repositório adicional pages, já que
isso seria irritante e rapidamente me faria sentir falta da CI do GitLab. Por
isso eu adicionei um novo comando make deploy no Makefile para automatizar o
processo de publicar o site no repositório pages. Ele pode ser visto nesse
commit.
O que o make deploy faz é:
- Fazer os passos anteriormente feitos no .gitlab-ci.yml para gerar os
arquivos de saída do blog, especificamente:
- Gerar as strings de tradução (através do
make trans_deploy) - Gerar as páginas do site (através do
make publish)
- Gerar as strings de tradução (através do
- Commitar os arquivos de saída e fazer push deles para o repositório
pages
Já que os arquivos de saída gerados pelo pelican precisam ser commitados e
enviados para o repositório pages, a pasta local de saída dentro da pasta do
blog agora precisa ser um repositório git. Para permitir isso, a variável
OUTPUT_RETENTION precisou ser atualizada para que
o pelican não delete a pasta .git toda vez que ele rodar.
Em seguida eu melhorei as mensagens de commit para o repositório pages
através desse commit, formatando elas com tanto o hash quanto a descrição,
no mesmo formato que é usado para as tags Fixes: no kernel Linux. Isso
me permite não apenas correlacionar todo commit no repositório pages ao
commit correspondente no repositório blog, mas também facilmente identificar
sobre o que foram as últimas mudanças.
Eu também adicionei um arquivo .domains à retenção já que ele é
necessário para usar um domínio customizado com o Codeberg.
Conclusão
No começo a necessidade de versionar os arquivos de saída com Git me pareceu desagradável, mas o fato de ser em um repositório separado e ser fácil relacionar os commits aos fontes fez com que isso deixasse de ser um problema para mim.
Inclusive, eu percebi duas vantagens nessa estratégia do repositório pages
em relação a ter uma CI. Primeiro, eu não preciso mais pensar nas versões de
imagens e pacotes que estão sendo usados na CI porque não há CI. Desde que meu
sistema local seja capaz de gerar o blog, tudo continuará funcionando (e eu já
precisava ter uma configuração local de toda forma para conseguir testar as
mudanças antes de enviar). Segundo, assim que eu rodo make deploy as
mudanças são aplicadas instantaneamente no site, enquanto na CI do GitLab
levariam em torno de um minuto para atualizar.
Então foram necessárias algumas pequenas mudanças para ter uma boa configuração do blog no Codeberg mas eu estou feliz com a mudança. O Codeberg parece um ótimo novo lar e eu vou fazer questão de cuidar bem dele 🙂.