From Fedora Project Wiki
< User:Bkabrda | BuildSys
Line 51: | Line 51: | ||
* All chroots for a single copr always have the same Fedora/epel release, but may contain more architectures. | * All chroots for a single copr always have the same Fedora/epel release, but may contain more architectures. | ||
* Each repo must point to a url, that has to contain arch specific dirs (i386/x86_64), each containing repodata dir (like koji has it). | * Each repo must point to a url, that has to contain arch specific dirs (i386/x86_64), each containing repodata dir (like koji has it). | ||
* EDIT [Oct 29]: the build now has a "chroots" attribute too, because chroots of a copr can change before it is built - and we want to build what was submitted. | * EDIT [Oct 29]: the build now has a "chroots" attribute too, because chroots of a copr can change before it is built - and we want to build what was submitted => the chroots from the build should be used. |
Revision as of 09:46, 29 October 2012
BuildSys Frontend <-> Backend API
Getting Waiting Builds From Frontend
To get 10 oldest submitted builds (this is currently a hardcoded default, do we want anything else?), use http://deployed_frontend_instance/waiting_builds/ - JSON is returned by default, example response:
{ "builds": [ { "copr_id": 5, "user_id": 1, "results": null, "started_on": null, "copr": { "owner_id": 2, "repos": null, "chroots": "fedora-17-i386 fedora-17-x86_64", "id": 5, "name": "ff2" }, "submitted_on": 1351157544, "ended_on": null, "pkgs": "http://foo/pkg.src.rpm", "chroots": "fedora-17-i386 fedora-17-x86_64", "id": 5 }, { "copr_id": 3, "user_id": 1, "results": null, "started_on": null, "copr": { "owner_id": 1, "repos": "http://foo/repo http://bar/repo", "chroots": "fedora-rawhide-i386", "id": 3, "name": "baz" }, "submitted_on": 1351153692, "ended_on": null, "pkgs": "http://foo/pkg-1.src.rpm http://foo/spam-2.src.rpm", "chroots": "fedora-rawhide-i386", "id": 4 }, ] }
* When multiple items are present in an entry (pkgs, chroots, repos), they are always separated by one space. * All chroots for a single copr always have the same Fedora/epel release, but may contain more architectures. * Each repo must point to a url, that has to contain arch specific dirs (i386/x86_64), each containing repodata dir (like koji has it). * EDIT [Oct 29]: the build now has a "chroots" attribute too, because chroots of a copr can change before it is built - and we want to build what was submitted => the chroots from the build should be used.