From Fedora Project Wiki
Line 20: Line 20:
         "name": "ff2"
         "name": "ff2"
       },
       },
      "canceled": null,
       "submitted_on": 1351157544,
       "submitted_on": 1351157544,
       "ended_on": null,
       "ended_on": null,
Line 38: Line 39:
         "name": "baz"
         "name": "baz"
       },
       },
      "canceled": true,
       "submitted_on": 1351153692,
       "submitted_on": 1351153692,
       "ended_on": null,
       "ended_on": null,
Line 52: Line 54:
  * 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 => the chroots from the build should be used.
  * 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.
* EDIT [Oct 29]: the build now has a "canceled" attribute - canceled builds will not be listed in waiting builds any more (do we want to support canceling builds on backend, or will we just throw the results away?)

Revision as of 10:59, 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"
      },
      "canceled": null,
      "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"
      },
      "canceled": true,
      "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.
* EDIT [Oct 29]: the build now has a "canceled" attribute - canceled builds will not be listed in waiting builds any more (do we want to support canceling builds on backend, or will we just throw the results away?)