Show users build position in queue

[donny-dont]

A common issue I am having with Drone is that the users do not know the number of builds ahead of their build. If there is a large queue waiting to be serviced they think that Drone is down which is often not the case.

I would like to create an API endpoint that takes the build in question and returns the number of builds ahead of them within the queue. This would not tell the user the builds in front of it just the number so they cannot figure out what builds are in front of them. This can then be beamed to the user through the UI.

Any particular things to look at or requirements for an implementation so I can start getting it sorted?

[bradrydzewski]

I'm kicking around an idea for an alternate approach ... but first there are some technical constraints that I want to point out so that my proposal makes a bit more sense.

Constraints

First is that we don't want to have to match the queue against the user's repository list. This is an expensive operation and should be avoided when possible.

Second is that we cannot show users items in the queue they don't have access to. In a corporate environment this may not be a problem, but for public facing instances this may not be desirable (especially hosted drone.io)

Proposal

I propose exposing an endpoint that returns the queue (we can query the database for this). The endpoint will return the following fields for all items in the queue:

• index in queue
• repo owner
• repo private (true/false)
• commit author
• commit sha
• build created
• build started
• build status

If the repository is public OR if the authenticated username matches the commit author username, then we can also display the following fields:

• repo name
• repo full name

The benefit here is that we don't expose sensitive information such as repository names or commit messages by default. We only expose this information if public or we can confirm the user owns the commit.

Limitations

This does mean we may hide commit details for a private repository the user has access to if they aren't the author, however, this is a valid tradeoff for not having to validate user permission for each queue item. I think the pros here vastly outweigh the cons.

Sample Payload

This is a sample payload for requests coming to /api/build/queue? Need to verify the exact endpoint that we want to use.

[{
  index: 0,
  sha: "966feeb0b3acb3f5f7b9fe80d398a9b9a3f2f21c",
  owner: "drone",
  name: "", // hidden
  full_name: "",  // hidden
  private: true,
  status: "running",
  author: "octocat",
  created_at: 1468449314,
  started_at: 1468449204
}, {
  index: 1,
  sha: "3cd8a399ece51751bdfcdc4b8ecc8f837ce261ba",
  owner: "drone",
  name: "drone-foo", // visible because it is my commit
  full_name: "drone/drone",  // visible because it is my commit
  private: true,
  status: "pending",
  author: "bradrydzewski",
  created_at: 1468449314,
  started_at: 0
}]

[gtaylor]

As long as private corporate setups can opt to see the full queue, this sounds reasonable. Without that option, the endpoint wouldn't be of much use to us right now. Though we are but one corporate Drone user.