Copr <3 Modularity
dev copr fedora
Modularity is an exciting, new initiative aimed at resolving the issue of diverging lifecycles of different components within Fedora. The building block of this idea is a module, which is a set of RPM packages that are well tested together as a solution. Module defines its components and dependencies and then it can be built into artifact such as repository or container.
Modularity in Copr
In last releases we introduced a lot of interesting things regarding modularity. You can now use
copr-cli for submitting an existing modulemd to be built or alternatively generate modulemd from your project through few easy steps in your browser. We also made a cool UI for viewing modules. Let's see how you can build something.
How to submit a module via copr-cli
There is a new command
copr-cli build-module ... for submitting module builds into Copr and it is very easy to use. It expect you to select one of the optional parameters
--yaml to specify a modulemd source. And that is basically it. You can also specify an owner and project name like you can do it for other
# Most simple is just to submit a build from localy stored modulemd yaml file copr-cli build-module --yaml ~/git/testmodule/testmodule.yaml # Guys from Factory 2.0 may be also interested in submitting yaml files stored in some SCM copr-cli build-module --url git://pkgs.fedoraproject.org/modules/testmodule.git?#9082569 # To specify an owner and project name, use positional argument as usual copr-cli build-module --yaml ~/git/testmodule/testmodule.yaml @copr/testmodule
Watch this two minutes long video to see building modules in action
Let's very briefly talk about how this works. There is a Module Build Service (aka MBS) which orchestrates all the magic related to modules. It takes care about obtaining the dependencies for the module, order in which they should be built, etc. Copr runs own instance of this service and after you submit a build to the frontend, it passes it to MBS which takes control about it and orchestrates the rest of the process. If you want to know more, look forward to an upcoming article about implementation details.
Try it and tell us the limitations. What needs to be improved in order to make you start using this feature?
Few limitations we already know about:
- When submitting via
--urloption, only certain URLs are allowed (pkgs.stg.fedoraproject.org and pkgs.fedoraproject.org). This restriction comes from MBS (issue #513) and hopefully should be removed soon.
- No user access to logs. Unfortunately when something fails and it shouldn't, you have to ping an admin to examine the logs, you can't do it by yourself yet
In next article we will look on generating a modulemd from a copr project and building it without any knowledge about creating modules whatsoever. And where the development should proceed? It is mainly up to you and use-cases that you want to achieve. Let us know your ideas in the comment section below or on our mailing list.