Apresentando Jenkins no display com Raspberry Pi
No nosso ambiente de desenvolvimento, usamos Jenkins para Integração Contínua – a cada "commit" de código, compilar e testar a versão de forma automatizada.
No nosso ambiente de desenvolvimento, utilizamos Jenkins para Integração Contínua↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps →, ou seja, a cada “commit” de código, compilar e testar a versão de uma forma automatizada. Cada um pode se conectar no servidor Jenkins e visualizar o status do build, mas deixamos um display aberto para que todos possam ver como as coisas andam (e não deixar um release quebrado parado para sempre).
Nada melhor que usar um Raspberry Pi para essa atividade, já que é um dispositivo pequeno e com baixo consumo de energia. Aliás, é o treco pendurando pra baixo da TV. O único inconveniente é que, para mostrar mais de um servidor Jenkins, as opções atuais são para utilizar algum código JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) → que faz com que a tela troque de URL.
Essas soluções funcionam muito bem em PCs x86_32 e x86_64, mas em um Raspberry Pi… as limitações de CPU são grandes. Como os browsers que suportam isso são Chrome/Chromium e Firefox, o efeito indesejado é essa “lentidão” em renderizar a página, como mostra a imagem.
Outro problema é que se um dos servidores Jenkins estiver fora do ar, esses JavaScripts “quebram”, não fazendo a transição para a URL seguinte.
Para completar o problema, decidimos mudar de Chromium pra Epyphany, pois este usa muito menos memória que o Chromium, e menos CPU. Mas nem tudo é perfeito: o Epyphany não suporta script para trocar entre várias URLs como o Chrome.
Durante essas trocas de browsers e experimentos, troquei umas mensagens com o Gustavo Noronha, vulgo Kov, que é um dos mantenedores do Epyphany, perguntando sobre as possibilidades do navegador. Ele disse que Epyphany não suportava esse tipo de plugin, mas que eu poderia escrever minha própria aplicação em webkit. Então…
Demorou. Acho que trocamos essas mensagens, via Twitter, lá pro meio de outubro. Mas finalmente escrevi alguma coisa.
Comecei com um pequeno script baseado num código em C++ com Qt:
#include
#include
int main(int argc, char **argv){
QApplication app(argc, argv);
QWebView wv;
QWebPage *page = wv.page();
QWebSettings *settings = page->settings();
settings->setAttribute(QWebSettings::JavascriptEnabled, true);
settings->setAttribute(QWebSettings::PluginsEnabled, true);
wv.load(QUrl("http://www.youtube.com"));
wv.show();
return app.exec();
Acabei trocando o script simples pra uma classe em Python, e usando threads. O que era simples ficou um pouco mais… vamos chamar de “refinado”. Mas está funcionando. E com menos memória e CPU, que era o objetivo inicial.
Quem quiser dar uma brincada ou mesmo usar, o código está disponível no GitHub.








