Here is another use case:
The set of stages run for each build is based on the parameters specified when the build was triggered.

node
{
   stage 'Build Stage'
   echo 'Do build'
   if (TestingEnabled)
   {
      stage 'Run test'
      echo 'Do run test'
   }
}

+1 for this enhancement.

I have a pipeline that builds a number of other pipeline jobs. However, this orchestration pipeline determines what it needs to build based on a set of parameters. It can build anywhere from 1 - 6 different jobs, and each of these jobs is built within a stage. Unfortunately, with the current implementation, I can't get an accurate visualization of what stages actually ran for previous builds.

Agreed this is useful - in the near future I will take a look and see what we can do; there are related pieces of code that need to be touched at the same time (around the UI rendering process), so it would be a logical pair to include.

I should add that doing this the right way is probably more complex than it would appear at first blush: you need to somehow associate stages with the same name across runs, even if the stage count differs. Also, the computation of average runtime for stages would need to be aware of this.

Do-able. just complex.

I'm not sure if this belongs here or in another issue.

I observed that if I have more than one stage, and I use the replay feature to re-run any stage other than the first stage, I also lose my UI history.

I also observed that if I replay just the first stage, my UI history remains in tact.

This is an important feature to me, because if I have a temporary environmental issue that caused a deploy failure in one of my stages, I want to be able to replay that specific stage and not lose the UI history.

Hi there,

We are going to be solving a lot of similar problems to the Stage View plugin in the new Blue Ocean UI. In the case of this ticket, we do not believe Blue Ocean suffers from this issue.

If you haven't heard of Blue Ocean yet, take a peek at the introductory blog post, install the plugin from the experimental update center and give us feedback on the Jenkins Users mailing list.

If anyone feels like picking up this ticket in the future, please feel free to reopen it and assign it to yourself.

Thanks,
James

I don't see how Blue Ocean UI solves this, as it's basically a much more cut down version. I cannot find any history where it shows all stages.

I want to reopen this, because I do no see how this is complex. First iteration could be just showing completely separate lists. No cross-referencing required. This is exactly what the mockup shows.

The ticket doesn't state that accurate history of stages is even required. Heck, I find the "build time prediction" features annoying in Jenkins, because it's never predictable for complex scenarios anyway and it ends up totally incorrect most of the time.

We are not actively improving the Stage View at this time. If someone from the community wants to work on this problem specifically, please reopen and assign it to yourself.

gl1koz3 FWIW (as part-time maintainer of Stage View) doing this in a reasonable way when stages change is much, much harder than you'd expect – and exponentially so if you want to handle things like stage renames. 

You're basically trying to overlay one arbitrary graph structure upon another, if you want to solve the most general form of this problem.  Then you're trying to visualize it.  

The feature is time-prohibitive unless a community contributor has a clever idea.

I'd like to add my vote to this issue, but the option seems disabled - is it because this issue is marked "Resolved"?

I'm not a contributor, and realize that there are often thorny details the user doesn't see, but it seems like there might be a big difference between solving the general form of the problem and just implementing a minimal use case (no cross-referencing, no renames, etc.) that achieves the main goal of visualizing old builds.  I'm not sure it's really a new visualization combining all the history that's desirable.  A user (I think) just wants to be able to see the same visualization they saw the day before, somewhere in the UI, even if it can't include the newer builds. 

In my mind, it's not even a prerequisite for all the sequences of builds to be on the same screen as long as you can find them somewhere.  For instance, based on the mockup screen example, what if:

• If the user clicks on the project page "TestProject" it shows the same Stage View it would show today, with the recent builds #4, #5, #6 that have the same stages.
• If the user clicks the build page for #3, it would have a new link "Stage View History", which would open a display showing what the Stage View used to look like - build #3 with the old stages
• If the user clicks the build page for #1, it also would have "Stage View History", which would show the even-earlier Stage View - build #1 with just the two stages.
• Or to make it a better example, if there were a build #2 with the same stages as #3, the Stage View History for build #3 would show two builds #2 and #3, so that even though these two builds weren't with the current stages, you could see them shown together because they had the same stages.

Don't the build logs have all the information the UI would need to do that?  Wouldn't the current algorithm suffice, just pretending the older build is the latest build that it must count the stages from?

Thanks!