Miloslav Suchy delivered a report on the state of Copr yesterday at Flock that demonstrated just how far a service can go in one year. Work on Copr, the lightweight build service for contributor packages that aren’t yet in Fedora officially, started less than a year ago. But the service is already hosting more than 250GB of data and has churned out more than 25,000 builds!
What’s Copr? In a nutshell, it’s a system for building packages and offering repositories for packages that aren’t yet in Fedora or aren’t ready for Fedora – for example, GNOME 3.12 built for Fedora 20 for users who want to go to the latest GNOME before the next Fedora release. Or experimental builds of packages.
Before work on Copr started, there was discussion about re-using Koji or the Open Build Service (OBS). However, Suchy says that Koji was more complicated than they wanted, and OBS used different scripts to build packages – and there was a concern that Copr and Koji might produce different builds of the same packages. In the future, Suchy says there’s a possibility that Copr might switch to OBS, but for the time being, it’s its own product.
Challenges Building Copr
Though the team has made swift progress, it’s not been without challenges. For example, Suchy mentioned that Copr makes use of OpenStack to create new virtual machines to build packages, then destroy the VM after a successful build. The rationale for this is that they want a clean environment for each build, so re-using the same VMs isn’t an option.
That’s an ideal use case for OpenStack, but Suchy noted that Fedora Infrastructure currently has an aging version of OpenStack, and it’s been tempramental – which can cause problems when you depend heavily on the infrastructure as a core piece of your service.
On the plus side, Suchy says they expected problems with legal issues – folks attempting to host packages in Copr that don’t meet legal guidelines – but that hasn’t been a major problem.
There are several integration points with Copr that fit well with different developer workflows. Suchy mentioned that there’s a few CLI tools that integrate well with Git and make it easy to create and send source RPMs to Copr and get the resulting package. There’s also a Jenkins plugin that will test the package and then send to Copr for building when the tests are successful. With DNF, you can simply use something like "dnf copr enable msuchy/foo" and it will automagically set up the repository and let you grab packages.
Copr has made great strides, but it’s not done yet! Suchy says that a few major features are coming soon to Copr that many developers will be happy to see.
One of the biggies is package signing, which is a piece that’s currently missing from Copr. The service is also getting more storage soon, which is important given the growth rate of Copr. (The service is currently using about 30% of its storage space, but that can be consumed quickly.)
Importantly for Copr’s uptime, Fedora infrastructure should be rolling out a new OpenStack instance soon, which should be more reliable for the service.
Finally, Suchy says that ARM builds will soon be available for Copr, which is great news for folks who want to use Fedora on ARM with packages not part of the official distribution.
In all, Copr is proving to be a vital service for the Fedora community, and there’s a lot more coming in the next year that will make it even more useful.