I wrote it as a PoC ~2 years ago, but can't find the code now :-(. It
wasn't a plugin nevertheless, more an option for build tasks to use docker
api instead of mock. It was working somehow - my goal was to use buildroots
as preinstalled layers (instead of running newRepo, docker image was
created). So, it is doable and it is not that much work - as a plugin on
the other hand it would mean replicating a lot of code from kojid.
Reason to not continue on was Abstract Buildroot Interface [1] which would
make it a lot easier. We should find some time to continue on this :-)
[1]
On Mon, Nov 30, 2020 at 8:18 PM Leonardo Rossetti <lrossett(a)redhat.com>
wrote:
I wanted to write a plugin where a task would run in a kubernetes
pod
instead of using mock in the "local builder".
I know mock is not abstracted, but how a task is run is, isn't it?
I was taking a look at the "runroot"[1] plugin source code and it looked
like (to me at least) that it overrides the default behavior when a task
needs to be run (such as building an RPM por example), is that correct?
[1] -
https://pagure.io/koji/blob/master/f/plugins/builder/runroot.py
On Mon, Nov 30, 2020 at 4:03 PM Michael McLean <mikem(a)redhat.com> wrote:
> This is possible, but it is probably more work than you expect.
>
> Mock is not abstracted in the code, so you can't simply swap out mock for
> something else. You'd need to write new method handlers.
>
> There is also the matter of how to trigger such builds. If this plugin
> adds new build methods, then you'd likely need a hub plugin to create the
> task(s) and a cli plugin to provide the command.
>
> I suppose you could alternately override the `buildArch` method if your
> approach could work as a drop-in replacement for it, but it's unclear what
> exactly you are trying to accomplish.
>
> On Mon, Nov 30, 2020 at 12:35 PM Leonardo Rossetti <lrossett(a)redhat.com>
> wrote:
>
>> Hello,
>>
>> I was taking a look at this page:
>>
https://docs.pagure.org/koji/writing_a_plugin/ and I was wondering if a
>> plugin could be written to provide an alternative build/isolation system
>> instead of the default one.
>>
>> Would it be possible to write a builder plugin that would not use mock
>> as the isolation system?
>>
>> Regards,
>>
>> --
>>
>> Leonardo Rossetti
>>
>> Senior Software Engineer,
>>
>> Red Hat <
https://www.redhat.com>
>>
>> lrossett(a)redhat.com
>> <
https://www.redhat.com>
>> _______________________________________________
>> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
>> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct:
>>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>>
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
>>
> _______________________________________________
> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
>
--
Leonardo Rossetti
Senior Software Engineer,
Red Hat <
https://www.redhat.com>
lrossett(a)redhat.com
M: +55-11-99703-0621
<
https://www.redhat.com>
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
--
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat