Build status aggregation (please, just not the first status)


 please see the following image:

it seems that in the git-tree view Upsource shows the very first badge it obtains. Which is annoying since it hides the actual result of the build.

Could you please change it such that it shows the very last build status instead?

Or sometimes it happens that the build fails and then subsequently passes. Then neither fail nor pass make much sense. Could you please introduce some yellow (or whatever) badge which would indicate mixed results in the build?

We are running v2017.2.2398

Thanks a lot


Hi Vojtech,

Thank you for your suggestions.

What should be considered as "last build status"? 

As for yellow badge suggestion, it sound really cool, just posted the corresponding request -


Well I've been just playing with the API and I do not fully understand the logic which reduces the build statuses to the single badge, but according to the following image

not only the failed badge but also the in-progress badge overrides the success. I would be pretty much happy with either (let me use pseudocode)


def merge(buildStatuses: Seq[BuildStatus]):Option[BuildStatus] = buildStatuses.lastOption




def merge(buildStatuses: Seq[BuildStatus]):Option[BuildStatus] =
if (buildStatuses.contains(Failed)) {
} else if (buildStatuses.contains(Success)) {
} else if (buildStatuses.contains(InProgress)) {
} else {


The first is consistent because it let's user's CI decide what the latest outcome is. The second prioritizes failures over successes over (rather non-informative, just nice to know) in progress.

The current state where in progress overrides the previous / latter successes just does not work for me.



Also it'd be really nice if we could see the build status in the list of reviews (https://host/project/reviews)...


Hi Vojtech,

Build statuses are per revisions. Meanwhile, reviews may contain several revisions, what "build status" a review should have?



  • In a case of a branch review it's likely the status of the latest commit
  • For a non-branch tracking review probably nothing, since it might not make much sense... Or the same as above

Please sign in to leave a comment.