As part of our third party story, we would like to make "offline local builds" possible so that people without access to our (or any other relevant) infrastructure can still run local builds with just the content they have available.
I imagine this should be fairly simple to implement. It could be a switch passed to the local build code that would use locally available repository content for module dependency resolution and as the source of packages.
We could construct a mock config based on the local repository configuration. Defaults would be part of the platform module in this case. Enabling modular dependencies could be done by issuing dnf module commands in the mock chroot or by overriding the defaults by supplying custom defaults in another, locally generated repo. The platform module stream should be ignored in this case.
platform
dnf module
If I'm missing something obvious, let me know in the comments :)
@langdon @asamalik @sgallagh
@lucarval, this is equivalent of fedpkg local and is really important for testing module builds locally and playing with modules generally without using any external infrastructure. It is frequent issue people have when testing modules for first time.
fedpkg local
We have discussed doing exactly this RFE during the grooming to address most of the issues we have open for current local builds.
@psabata, imagine this RFE is implemented and we also have scratch-builds. Is there a need for current MBS local builds functionality? To remind you and others how it works currently: MBS queries official MBS instance to find out the buildrequires of your module, downloads the RPMs to your machine (or in case the repo exists in Koji, it uses the Koji repo), constructs the repositories locally and build the module locally in mock against these repositories.
I would personally remove the current code for local builds and support only the new way described by you in the RFE.
@jkaluza I would prefer you kept the current code. I wouldn't want to lose the ability to test my changes locally, even if scratch builds are available. The environments are different -- various platforms, buildroot-only modules not available in the repos, and so on.
I'm wondering if the fedpkg local behaviour could be achieved using the new functionality proposed by this issue along with the right content being generated by the infra as standard repositories. Having two very different code paths for a very similar functionality doesn't seem optimal.
We should aim on reducing the overall complexity. I find myself questioning the existence of the 'buildroot-only' modules yet again.
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/mbs/issues/1150
Please continue any further discussion there.