I've been noodling around with how to allow for arbitrary things to be run prior to the actual building of the pkgs. This is to allow for a wide range of 'sources' of pkgs.
I talked with Slavek at summit briefly and we talked about a way to handle the giturl-of-doom or turning various arbitrary blobs into srpms.
The gist of it is this - we have a place we can do it in the code we have but we will need to change how builds are being spawned.
Right now we just a direct ansible call to execute mockchain and get the srpms building. This is simple and immediate but it means we have to modify code every time we want to add another step.
I'm thinking we use a playbook instead of a direct call. This helps us b/c it means the playbook is easier to modify and we can get the log results out of its objects.
for anyone not familiar with ansible playbooks see here:
http://www.ansibleworks.com/docs/playbooks.html
Here's is the framework I was thinking of:
playbook:
play - setup/create builder - provision it - add mock configs, etc
play - verify state of the builder
play - download srpms/pkgs/giturls/etc - make into srpms (optionally) - check integrity of srpms - check licenses - essentially run the rpmlint license checker - attempt buildorder sort? (optional but could be handy for a number of cases - this is using this code: http://skvidal.fedorapeople.org/misc/buildorder/ - mockchain build srpms - async (perhaps to make it easier to timeout - harder to retrieve logs) play - download results
play - destroy builder
This playbook would let us modify the playbook for the type of system (for example the mechanism to spin up an arm-builder is very very different from an x86[_64] vm.
The way I figure this would allow us to insert a set of random tasks into the entire build process w/o having to add more code - just add more plays into the playbook.
thoughts? -sv
On 06/24/2013 05:43 PM, seth vidal wrote:
I talked with Slavek at summit briefly and we talked about a way to handle the giturl-of-doom or turning various arbitrary blobs into srpms.
I suggest that the tool turn-git-to-srpm-o'matic should not be part or copr itself. It should be separate project. And there are already some existing. E.g. Tito, or {cpan,gem,...}2spec + rpmbuilder and probably others. Yes - copr can use them and utilize them.
playbook:
play
- setup/create builder
- provision it
- add mock configs, etc
play
- verify state of the builder
play
- download srpms/pkgs/giturls/etc
- make into srpms (optionally)
- check integrity of srpms
- check licenses - essentially run the rpmlint license checker
- attempt buildorder sort? (optional but could be handy for a number of cases - this is using this code: http://skvidal.fedorapeople.org/misc/buildorder/
- mockchain build srpms
- async (perhaps to make it easier to timeout - harder to retrieve logs)
play
- download results
play
- destroy builder
No objections here.
On Tue, 25 Jun 2013 09:31:05 +0200 Miroslav Suchý msuchy@redhat.com wrote:
On 06/24/2013 05:43 PM, seth vidal wrote:
I talked with Slavek at summit briefly and we talked about a way to handle the giturl-of-doom or turning various arbitrary blobs into srpms.
I suggest that the tool turn-git-to-srpm-o'matic should not be part or copr itself. It should be separate project. And there are already some existing. E.g. Tito, or {cpan,gem,...}2spec + rpmbuilder and probably others. Yes - copr can use them and utilize them.
I agree. The whole point of the playbook is to run other programs.
I don't know what the turn-git-to-srpm-omatic would do - Slavek said Radek was very interested in that ability. When Slavek and I talked about it at summit I said - I don't know what particular tool would be used to do that conversion but if the url that we git from the user for a package is NOT a srpm then we should just pass it off to this program and move merrily along.
-sv
copr-devel@lists.fedorahosted.org