User:Bkabrda/BuildSys/API

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": false,
      "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": false,
      "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?)
* EDIT [Oct 30]: it may be useful to have "successful" attribute, that would show the result state - could the backend be modified to push an information like that?

New draft:

{
  "builds": [
    {
      "user_id": 1, # id of user who submitted the build
      "submitted_on": 1351770919,
      "repos": "http://repo", # urls of repos to add to mock chroot, separated by space
      "results": null,
      "started_on": null,
      "copr": {
        "owner": {
          "id": 1, # id of the owner of copr (not necessarily the same as user_id above)
          "name": "bkabrda" # FAS name of the user
        },
        "name": "asd", # name of the copr
        "id": 1 # id of copr
      },
      "canceled": false, # non-canceled builds will not show up here, I can put this away, too
      "ended_on": null,
      "pkgs": "http://package", # urls of packages to build, separated by space
      "chroots": "fedora-16-i386 fedora-16-x86_64", # chroots to build in, separated by space
      "id": 14 # id of the build
    }
  ]
}