build status with tag change

I am using gradle and versioning and for this I need a tag like v0.1. I forgot this for a particular project and the test runs, fails... I realise I need to add the tag. Job runs immediatly again and it succeeds. However the badge still shows an error?

https://gitlab.com/sapp/GeneticElements/crt/commit/ca1fb76e1735450b907a420d4efdde731195b183/pipelines

Is this intentional or is this a bug?

@jjkoehorst Thanks for the report. That doesn't seem right. I'll try to reproduce it.

added ~19173 pipeline labels

I was able to reproduce it on GitLab.com here:

• https://gitlab.com/issue-reproduce/more-than-one-pipeline-status-for-commit/commit/f0b3642dacea952f7be0239543fabf91af6594db/pipelines

added ~12980 reproduced on GitLab.com labels

It seems that the latest status for the commit isn't being used here

/cc @godfat

I haven't taken a closer look at the code, but previously we show the compound status of all pipelines, and if that's the case this would be somehow expected.

However even if that's the case, this is still confusing because it's showing as if the latest pipeline. And indeed we changed to be showing latest pipeline in some cases. I am not sure if we're still showing compound status somewhere.

I'll check the code.

ok, this is definitely confusing and we should change it. The related code was in app/views/projects/commit/_commit_box.html.haml, I'll paste the code on the bottom.

Here in the widget the first icon was showing the status of the compound status, which is failed because one of the pipelines was failed. Therefore we're saying that the "pipeline" failed, which is not the case, because the pipeline actually succeeded.

We should either:

0. Always show the status for the pipeline, therefore discarding compound status.
1. Or do the above, and also make compound status clear instead of confusing.
2. Or remove pipeline status here, and always show the compound status.

(1) would be the easiest, but we would be removing information (which we already did in some places)

(2) would require some UX thoughts.

(3) would also require UX thoughts, and it could confuse the users because the concept was confusing from the beginning, and we also already stopped using it in some places.

Below was the code. We could just change @commit.status to @commit.latest_pipeline.status to do (1)

- if @commit.status
  .well-segment.pipeline-info
    .status-icon-container{ class: "ci-status-icon-#{@commit.status}" }
      = link_to namespace_project_pipeline_path(@project.namespace, @project, @commit.latest_pipeline.id) do
        = ci_icon_for_status(@commit.status)
    Pipeline
    = link_to "##{@commit.latest_pipeline.id}", namespace_project_pipeline_path(@project.namespace, @project, @commit.latest_pipeline.id), class: "monospace"
    = ci_label_for_status(@commit.status)
    - if @commit.latest_pipeline.stages.any?
      .mr-widget-pipeline-graph
        = render 'shared/mini_pipeline_graph', pipeline: @commit.latest_pipeline, klass: 'js-commit-pipeline-graph'
    in
    = time_interval_in_words @commit.pipelines.total_duration

/cc @grzesiek @filipa

Also, I realized that the duration was also summed from all the pipelines: time_interval_in_words @commit.pipelines.total_duration

Can we at least fix this in %9.2?

changed milestone to %9.2

Thank you for the report @jjkoehorst! Thanks @godfat for the detailed explanation

@ayufan what do you think is better? @godfat suggested one of 3 options

Here's a related issue from months ago https://gitlab.com/gitlab-org/gitlab-ce/issues/20560 /cc @bikebilly

@dimitrieh I couldn't help but want to know what do you think about this. You could also read #20560 (closed) for some background. Some explanation is located at https://gitlab.com/gitlab-org/gitlab-ce/issues/31378#note_28248319

We're also hitting into this in https://gitlab.com/gitlab-org/gitlab-ce/commit/d3123f67f1ee891a284e1a37a02c8efcffbee0f0/pipelines

I am also thinking that perhaps we shouldn't show the latest pipeline in the box, because it's already there on the top of pipeline list. However there's also a "Changes" tab, which is the default, and of course we would want to know the pipeline status on that page.

I think the main issue is that we're not clear what is a compound status yet, and we're also not explaining what it is clearly yet.

Labeling UX too.

Here's an even better example. Note that two pipelines are completely different.

https://dev.gitlab.org/gitlab/omnibus-gitlab/commit/5068f2fa5ca45f21eb36b355ba9bbabe15254b6a/pipelines

https://gitlab.com/gitlab-org/gitlab-ce/issues/31378#note_28248319 is great explanation. I made user friednly version

which is CHAOS who wants to know a compound status of two DIFFERENT pipelines.

⓵ and ⓷ should be removed? ⓶ and ⓸ should point the last id of those pipelines? ⓹ probably makes sense?

Thank you for this @dosuken123. This is a mess

@ayufan can we fix this for %9.2 ?

I believe it's very simple to fix it, we just need to decide what we want to do.

Compound status still has some value (as you can see that two pipelines are different, and we want to know the summary in some way. Of course, after we have multiple pipelines (#28592 (moved)?), then we probably won't care about compound status anymore, or we could say that would be the new compound status), but we can't confuse the users. Actually this is very similar to #20560 (closed). The difference is that we have much more space for the widget, so we could maybe show both information, if that fits and we care.

I should probably also mention that, our current badges are showing compound status.

This one is for master: https://gitlab.com/gitlab-org/gitlab-ce/badges/master/build.svg

This one is for 9-1-stable: https://gitlab.com/gitlab-org/gitlab-ce/badges/9-1-stable/build.svg

Here's a proposal for (2) in https://gitlab.com/gitlab-org/gitlab-ce/issues/31378#note_28248319

• Commit status: [badge showing compound status] in total pipelines time
• Latest pipeline #abc [latest pipeline status] [mini graph] in pipeline time

Compound status, as currently used, was never a good thing. It's too damn confusing. We have an issue somewhere to treat pipelines with different inputs as distinct pipelines. That lets us stop compounding status, at least at this level. Pipeline status badges might still need a compound status (although at least they can distinguish different refs), and merge requests probably need a compound status to determine merge-ability. But in many cases, we'd be displaying all related, distinct pipelines individually.

Proposal: Until we can treat multiple, distinct pipelines in a first-class way, let's stop half-assing it and just look at the latest pipeline instead. So, option 1 from @godfat's list.

FWIW, ⓹ from https://gitlab.com/gitlab-org/gitlab-ce/issues/31378#note_28471931 should not show compound duration.

I think we have enough of votes, so I'll change it to just show latest pipeline.

assigned to @godfat

Since we added a pipeline mini graph to commit status page, compound status indeed conflicts with it. I still think that compound status might be important, but we have to resolve this bug first. I suppose that two options that make most sense are reporting only latest pipeline status or showing multiple mini graphs. The latter may be quite complex.

I wonder how this relates to our plan of introducing multi-project pipelines / multiple pipelines and https://gitlab.com/gitlab-org/gitlab-ce/issues/25734 which is scheduled for %9.2. Once we remove compound status, we are not able to report a commit status based on deterministic pipelines group, because compound status is required for that. What do you think @markpundsack?

One solution might be reporting only latest pipeline status for the commit (which seems to be most favored solution here), but to tackle this problem for cross-project pipelines / mutliple pipelines differently, because the right solution might be completely different when cross-projects pipelines are implemented. I wonder if we have any data about how many users / customers depend on a compound status.

Medium term, let's solve it with https://gitlab.com/gitlab-org/gitlab-ce/issues/25734. Ignore multiple pipelines as that's not committed. Cross project pipelines will happen, but may not impact this for a while. First few iterations won't affect status.

Related https://gitlab.com/gitlab-org/gitlab-ce/issues/28494

@dosuken123 You found where this was introduced. https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9902/diffs#2ed11c292eb9613a1a54aa2b541da9d792fb161e_75_74

This is a perfect example that keeping the same behaviour could be wrong.

mentioned in merge request !11038 (merged)

closed via merge request !11038 (merged)

mentioned in commit 68c12e15