ref should be able to understand what sha1 has it built

[alfredodeza]

This presents a problem because the current URL structure is:

 project/ref/distro/distro_version/architecture/

So modifying this to accommodate sha1 (backwards incompatible) would look like

 project/ref/sha1/distro/distro_version/architecture/

The other option would be to not make sha1 part of the url, but part of the API. That is, ref would need to be told about the sha1 it is receiving, but this sounds problematic as the correctness would fully rely on the client and not the system. It would be tricky to ensure separation of sha1's across the board.

For example, when building a repository, code would need to be adapted to not mix different binaries from different sha1's.

I am not sure what is the best answer here, some users may not even want to have a sha1 in the url and that would be cumbersome to make it optional.

[ktdreyer]

I think it would be

 project/sha1/distro/distro_version/architecture/

(no ref there) right?

EDIT: I say this, because this is how gitbuilder is laid out currently.

[zmc]

@ktdreyer, that's not quite right. Here are two example URLs:
http://gitbuilder.ceph.com/ceph-deb-trusty-x86_64-basic/ref/master/
http://gitbuilder.ceph.com/ceph-deb-trusty-x86_64-basic/sha1/0ba2e145d08b0560f155e30f643ce6cf6c5b763c/

I think we will need to be able to query for builds both by sha1, and by branch.

[alfredodeza]

Seems like gitbuilders have two different structures, one for refs and another one for sha1s:

http://gitbuilder.ceph.com/ceph-rpm-fc22-x86_64-basic/ref/
http://gitbuilder.ceph.com/ceph-rpm-fc22-x86_64-basic/sha1

For refs it includes a file named sha1 to help understand what sha1 that ref points to. For the master ref that would be:

http://gitbuilder.ceph.com/ceph-rpm-fc22-x86_64-basic/ref/master/sha1

So that helps to answer "what is the sha1 this ref was built at?". However, for sha1's it includes the same file (nothing there to do a reverse mapping).

I believe that having the sha1 as part of the url would get rid of the problem, with the actual ability to do nifty things like adding latest:

 project/ref/latest/

[ktdreyer]

So that helps to answer "what is the sha1 this ref was built at?". However, for sha1's it includes the
same file (nothing there to do a reverse mapping).

Right, I think this is because the ref "master" is just a symlink on disk to the sha1 directory on disk. It does look weird from an API perspective but it's "just a bunch of files".

[zmc]

It'd be really helpful to also have the reverse mapping, i.e. sha1->branch. I realize that a given sha1 can be present in multiple branches, but at the time a build is initiated we might be able to assume it is only in one. Granted, that might invite a race condition

[alfredodeza]

This issue was moved to ceph/chacra#111