NH:STA S02E02 posted Wednesday, August 5, 2026 by The Neighbourhoodie Team NewsInterviewSovereign Tech AgencyFOSS
This post is part of our looking back on our work for the STA, formerly the Sovereign Tech Fund. Our introduction post explains why and how we contributed to various Open Source projects.
Introducing Poppler
Poppler is a PDF rendering library for Linux and Windows hosted by freedesktop.org. It’s a simple tool with interesting origins, and one you’ve probably interacted with if you’ve worked with tools like InkScape or LibreOffice, or use a Unix-based operating system like Gnome.
In the Wikipedia entry on Poppler, you’ll discover a web archive link to the project’s first README, from author Kristian Høgsberg, that outlines why the tool came into existence. And if you use open source technologies in your work, the problem of duplicate labor when patching distributed FOSS packages will be familiar. As will the desire to avoid it.
What We Worked On
At the time of writing Poppler is 21 years old! It has certainly achieved its goal of being widely adopted. But like any tool lovingly crafted by so many hands over so many years, it would have benefited from some focused attention to introduce new best practices, particularly regarding its continuous integration (CI). We feel very lucky that our team was invited to spend the time doing just that.
Continuous Integration (CI)
CI is a development practice of managing code changes through a pipeline that includes versioning, building, testing and deployment. A big advantage of CI is automating parts of the process to execute either on a schedule, or when a set of actions is identified. That could look like a test suite scheduled to run at the same time each day, or running certain regression tests based on what’s getting merged and in which environment. The end result is early identification of bugs, breaks and unintended side effects from new code additions.
Another great advantage of working with CI is centralising testing efforts. Thanks to the CI pipeline, developers can save time spent manually running tests locally before pushing their changes, or adapting their config to test a colleague’s branch. In open source projects, this is a huge advantage. As we’ve explored in previous STA projects, testing in general makes a project easier to contribute to and maintain longterm.
As you can imagine, it also makes it particularly gratifying for us to help with something that so directly saves time and contributes to improved project health.
Introducing Buildbot
Buildbot is an open source, python-based CI framework that’s used in some very well known projects — including Python itself. It’s an extremely flexible and powerful CI tool that comes with a myriad of configuration options to help with deployment and testing (hence the name!). As with much automation, what you put in is what you get out: it can take a good deal of effort to set up Buildbot for your specific use case and release pipelines, but it both takes over tedious manual work and provides feedback that saves time and pays dividends in the long run.
The Poppler team had worked with Buildbot already, and we picked up the baton to implement it as their CI framework. We are very proud to have set it up for their regression testing needs. Specifically, we configured Buildbot to:
- work out of a Docker-based configuration
- require authentication so only Poppler project members can view the tests
- run on every commit to Poppler’s main repo
- keep an eye on visual differences
- run on new merge requests
As we went, we prioritised maintainability and accessibility. We also made sure to upgrade the setup to run on Python 3 where it was necessary. That means documenting everything from architecture to components in a way that makes it easy for folks with both lots and a little experience to get up-to-speed.
Below we hear from Jan Lehnardt and James Coglan who worked on the project.
Reflections from the Team
What surprised you the most about adding Buildbot CI to Poppler?
Jan: Not a surprise per-se, but we were focussed on setting something up the the project could maintain in perpetuity on their own, so we chose technologies (Buildbot and Python) that the project was already familiar with and put things together in a transparent and reproducible way with additional documentation that should serve them for quite some time.
What was especially challenging about this project?
Jan: Poppler is a large project with a very idiosyncratic testing harness that took us a while to understand, but once we had it working, it turned out to be comprehensive and powerful. We were happy to be re-using an existing harness rather than inventing a new one. But we had to drag some of it from the Python 2 world to the newer Python 3 one.
Did you learn anything about CI integration with Buildbot and Python/Python 3 that will benefit Poppler going forward, or that you will bring into future projects?
James: Since it is so common these days for projects to use cloud-based CI systems, it’s been a while since I had had cause to set up a self-hosted CI system. However, Buildbot turned out to be quite straightforward to get started with, and to package for deployment, so it was definitely one of the more pleasant experiences I’ve had doing this sort of thing. But it also has enough depth that you can define more complex workflows with dependent tasks, locks, and so on, so it nicely scales up with project complexity. I’ll definitely keep it in mind as an option for future CI needs.
Conclusion
As with many of the projects we’ve supported through the Tech Resilience program, our work will have a direct impact on the developer experience at Poppler. We hope longstanding maintainers will experience a little moment of relief and joy as they wave goodbye to local testing and all it entails, and that new maintainers appreciate getting to skip local test environments altogether! And for end-users, we hope that the time freed up means new and nifty features come to life a little faster.
You can read more about the work we’ve done on different FOSS projects with the support of the Sovereign Tech Agency:
NH:STA S01E06 Reproducible Builds
NH:STA Special Episode with PHP
We Can also Help You Directly
Many companies and products have crucial dependencies on small and potentially understaffed and underfunded FOSS projects. We can help identify and improve the ones that are important to your business. Our friendly sales team is happy to help. Book a call with us today!
« Back to the blog post overview