"build" is a bad term here. Better is to see it as unique identifier for the collection of results  that kCI stores (for that set of built binaries we test). Of course we could just use a uuid but that does not give use a way to link back to the sources.

The reason is that in the kCI backend, we need a unique identifier. Results get stored under this identifier and overwrite previous results of the same identifier.

State of the discussion is these ideas:

• gerrit/CI:   changeNr+patchNr+jenkins-buildid
  • e.g.  c10969+p2+49
• more general:  AGLbranch + Machine + AGLfeatures + image-name + "repo manifest -r | sha1"    ( with or without timestamp added tbd )
• we could let jenkins generate/store a uuid alongside the binaries uploaded to download.AL.org

An important point to consider is that while above works within our own jenkins, how we can enable others (other labs, or e.g. Fuego) to contribute results to an existing entry.

Regardless of the above, we will likely want to store these as metadata within the job description (random order):

• repo manifest -r  (long text field)
• AGL branch
• MACHINE
• agl features used for the build
• (maybe  conf/local.conf  - long!)
• image name
• change ID + patch NR
• link to gerrit changeset
• link to jenkins build
• (maybe link to JIRA)

Lets go from here and research/discuss.