Duration of a single job may not tell us much about its performance, we want to add a new section that help comparing it with other similar/recent jobs.
Proposal
Create a page that shows more data about historic runs of a job from other pipelines.
just adding this without a way to get to it isn't the best UX but is probably ok for an MVC if we add documentation. We can think about the paths to get to the page from there.
This page is not yet connected to the rest of the UI (e.g. by a link) so I wouldn't know where to add docs I'll leave it to the team to how it works and move with docs! bows out gracefully
@mrincon@jheimbuck_gl Since all this data is related to one job, at first glance it makes sense to link to this page from the job page itself. We could have a "performance insights" button somewhere in the job page similar to this pipeline performance experiment.
The data on the job page like logs, artifacts etc. relates to that particular job run, while the job performance data is historical and relates to the job as a subset of the pipeline configuration. From that point of view, another place to surface this would be in the pipeline editor, as well as the CI/CD Analytics page.
In the pipeline editor we have a POC for an Analytics tab where among other stats users can view a graph with job execution time. We could link to the page with detailed job analytics there so users can drill into a table with detailed job duration for each run.
Adding @marcel.amirault for docs feedback as I should have before.
This page is not yet connected to the rest of the UI (e.g. by a link) so I wouldn't know where to add docs I'll leave it to the team to how it works and move with docs! bows out gracefully
@nadia_sotnikova - either the pipeline editor or the jobs page makes sense I think for the first iteration. depending on the results of the experiment we could add a link from there as well for slow jobs to their insights page. @v_mishra what do you think??
@jheimbuck_gl Thanks for the ping! There was no issue with this MR because it was simply my own initiative and not planned PA work. However, the work that I did during the hackathon did a lot of data massaging (AKA, changing the shape of API data to be usable by the clients) and is by no mean a finished product. What I was interested in was showcasing how we could give insights within the editor to help write better configurations.
If we think about the different angles of performance analysis that we want to do (at least in term of pipeline authoring priority) would be
Historic pipeline performance over time
Individual pipeline performance
An Individual job performance over time
I am mentioning this because in the context of PA, we want to show you how long your pipeline execution is and if that number has degraded or improved over time. Then, allowing you to dig into each specific job to see which could be the culprits to that increase/decrease of performance. I am not sure that seeing that data for each individual pipeline (again, in the context of PA) helps in any way.
The Editor performance analysis should focus on trends and help you get that average execution time down. I think that has @nadia_sotnikova mentioned above, having something either in the Pipeline editor or CI/CD analytic page would go a long way for this. I am not fully looped in to PE effort in performance analysis, but I think that from an editing experience, you'd want to have access to that data while working on the new CI config that will, hopefully, improve that performance.
either the pipeline editor or the jobs page makes sense I think for the first iteration. depending on the results of the experiment we could add a link from there as well for slow jobs to their insights page. @v_mishra what do you think??
@jheimbuck_gl to me both the locations seem important. Maintainer+ would like to be informed while optimising the pipeline and Developers would like to quickly understand the pattern of a problematic job.
I'd lean more towards the jobs page because a larger subset of users would be able to access it.
@marcel.amirault - I don't think that's where the data would actually live that's why I suggested the other two docs pages. Ultimately we'll likely get a version of this data/feature there and document it but for the MVC it'l likely live directly on the Jobs page.