Project page shows failed pipeline when most recent pipeline passed

If multiple pipelines are run for the same commit, and some of these pipelines fail, the project page shows that that commit has failed even if the most recent pipeline has passed. I would expect the project page to show "passed" instead of "failed". Clicking on the "failed" on the project page takes me to the successful most recent pipeline.

Added ~19173 label

Added ~12980 label

Milestone changed to %8.12

Reassigned to @zj

Mentioned in commit 00696765

Mentioned in commit b9d6682a

Mentioned in commit baf5a93d

Mentioned in merge request !6390 (closed)

@zj I'm moving that to 8.13.

Milestone changed to %8.13

Mentioned in commit e4d26ec5

Mentioned in issue #20223 (closed)

Mentioned in commit 8206f9a0

Mentioned in commit 2463453d

Milestone changed to %8.14

Mentioned in commit 0f6a1260

@ayufan @grzesiek According to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7034#note_17397201 actually we're not going to fix this because it's intended. What do you think? /cc @zj

I wonder if this is a good idea to take only the latest pipeline into account. I think that all pipeline for SHA/branch pair are relevant for commit status.

We can have a little different pipelines for SHA + branch, even though, the code is the same. I think it may be better idea to be inclusive here.

Another explanation is https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6801#note_17468470

We can have multiple pipelines for SHA/branch pair. Pipeline gets created when someone pushes the code. It can also be created using the UI (Run pipeline button). It can also be created using legacy builds triggers API (that will be replaced by new pipeline API). When someone uses API, he will be able to provide environment variables, what can effectively change the status of the pipeline, because pipelines are not deterministic for given SHA/ref pair. This means that status for the commit should be calculated while taking into account all pipelines. Does it make sense?

Let's ask @markpundsack and @ayufan about it.

Reassigned to @markpundsack

While your argument has some merit, there's also no question that the current behavior is wrong for this issue's case. The value of being inclusive is probably overcome by how often it is wrong. I think we should seriously consider only using the last pipeline's status.

If it helps to give a bit more detail about this case, these pipelines were API triggered nightly, and the failing builds were due to a problem upstream with the python docker image. So in this case it was unambiguous that the right status for the pipeline was passed.

In a way I'd like to see richer statuses on the project page, and better separation of (possibly dependent) jobs rather than single monolithic pipelines. For example, we have conceptually 3 jobs: fast tests run on push, slow tests run overnight (in reality this is achieved with an environment variable in the nightly trigger), and documentation (4 jobs if you count deploying to pages as a separate job to building). It would make sense to have separate statuses on the project page for each of these jobs. Separating jobs like this would remove the ambiguity that @godfat mentioned, where one pipeline can potentially be used for many different purposes. A single status for such a pipeline isn't very meaningful, however you construct it.

It would be best to have rich statuses, but that might need to go over some serious discussion and UX design first. Anyway, since this is a real issue right now, and we all seem to agree on that. What about we just change it to showing status from the latest pipeline in !7034 (merged) and consider this fixed?

@adelescott Would this work for you? Since it seems that you might also run into having different pipelines on the same commit and the same branch... What do you think? Would it be confusing if it always uses the latest pipeline?

Yeah, the most recent pipeline would make most sense for us and is going to be right in the majority of cases. Thanks.

Since !7034 (merged) was already merged, so we'll make a new merge request to make it show only from the latest pipeline.

Mentioned in commit 7de83a9b

Mentioned in merge request !7333 (merged)

Mentioned in commit 18a71c47

Mentioned in issue #24273 (closed)

@adelescott I have a question for you. You mentioned that you're using different environment variables to separate different "jobs". However you're still using the same branch, "master" for all of them. Would it work for you if you separate those jobs with different branches? I am asking this because showing only the latest pipeline would be somehow changing the behaviour, and we have some concerns about changing that in a minor version. /cc @grzesiek @ayufan

I don't think making a different branch would make sense for this. It is just running a subset of tests that are a bit too slow to run on every push, they're still logically part of the master branch of development.

In general this isn't a good solution either, because projects I've been on run things like a release job, a debug job, maybe a test line coverage job, or a static analysis job, all of which use the same branch. The basic assumption that one commit of one branch can have only one "status" is wrong. For my case, using the most recent status is the best compromise.

@adelescott Thank you for the input! Then I hope we could merge !7333 (merged) and that would also simplify the other stuffs I am working on right now.

By the way, I think pipelines should probably have a name, so that we could group by names just like we could group builds (jobs) by their names.

I believe that this is an important comment:

The basic assumption that one commit of one branch can have only one "status" is wrong.

@godfat I wonder if having https://gitlab.com/gitlab-org/gitlab-ce/issues/22972 would solve this problem. /cc @ayufan @markpundsack

@grzesiek I am not sure, since it might take a lot of works to do that, especially that we should make it backward compatible in some ways. (for example, having .gitlab-ci.yml versioned might be a good addition?

What I am thinking right now is, we could give pipelines names. Pipelines which are created by simple git push could be named default. Pipelines which created by web UI could have a new column to specify a name. By default it could also be called default. Or we could just say they're unnamed (NULL in database). Pipelines created by triggers could apparently take an additional argument to specify a name, along with other variables. Then we could group statuses by latest unique names, just like what we're doing for builds.

This should be simple enough while make the data available for us to show a list of statuses for a given commit. Mouse over to the status to show the name of the pipeline.

Milestone changed to %8.15

Mentioned in issue #25212 (closed)

mentioned in issue #25530 (closed)

closed via merge request !7333 (merged)

mentioned in issue #25734 (moved)

mentioned in issue #31378 (closed)

added pipeline label