Show failed jobs in MR pipelines tab part 5

What does this MR do and why?

Add failed jobs tract to MR pipelines tab

Behind a FF we add the ability to see failed jobs trace directly inside the pipelines tab of a MR. Failed jobs are only fetched when clicking on the button to expand the table. Then each failed jobs is fetched and can be clicked on to expand the job log and see why the job failed.

IMPORTANT Feature specs are also going to be written in the very last MR (or a separate MR, depending on size) to keep these really focus on FE only.

This is part 5 of 5 in a series of MR!

This is a complex MR We are adding polling and making sure to only poll when it is relevant. That means that we want:

• Poll for the job count when the widget is closed to get a rough number of how many jobs there are.
• We are now showing the "Show failed jobs (count)" at all times, not just when there are failed jobs. This is more consistent and since we needed to poll anyway to make sure that if a pipeline runs that had no failed jobs prior, the menu will update when there are. If we had shown nothing, then the text would have "popped" so it feels much nicer to see the count increment
• When the widget is opened, we stop polling for count and instead poll for the list of failed jobs and vice versa
• We only poll if the pipeline is active. This means that if you open the widget and the pipeline is not running, there is no polling! If the state changes, we start/stop polling accordingly
• There are sadly 2 sources of actions: graphql queries (this widget) vs the rest of the list, which is all in REST. This means that while we are polling, we check for pipeline.active field. If that value changes to false, it means that we should stop polling (the pipeline has finished). However, there are also REST actions like retrying the pipeline or stopping it. This is why we also have a second value isPipelineActive as a prop: if that changes, it means the REST call was sent and we now have a new pipeline state!
• We are also adding etags caching. This means that if we poll and hte pipeline state has not changed, you will see a 304 response header which is great for performance!

I have made several video that showcase some of these behaviours to help test this MR. Let me know if you need more info!

MR table:

Title	Link
Introduce FF and base component	!122914 (merged)
Fetch failed jobs	!122917 (merged)
Display each failed job in a row with log	!122921 (merged)
Add action button to each job row	!123086 (merged)
Add polling when the widget is opened	You are here

this is behind a disabled feature flag: ci_job_failures_in_mr.

Screenshots or screen recordings

Empty state

Widget closed - Polling for job counts

NOTICE: We start at 7 failed jobs. We retry and we poll until we get the same jobs back. The active property becomes false, and we stop polling. Also notice the last call is a 304 where we've hit the etag cache because we already had the latest data.

Screen_Recording_2023-06-22_at_3.23.36_PM

Widget opened - Polling for jobs when retrying a job

NOTICE: We open the widget: there are is no polling because the pipeline is not active. Then we retry a job, the pipeline become active and we poll. Then once we get the only retried job done, the active property becomes false and we stop polling.

Screen_Recording_2023-06-22_at_3.29.32_PM

Widget opened - Polling for jobs with REST actions

NOTICE: We retry a the whole pipeline (REST action), the pipeline become active and we poll. Then once we get the only retried job done, the active property becomes false and we stop polling. Note th efinal 2 calls: This is because since the action is REST, we want to make sure that we get the latest data from graphql as well before we stop polling, so we make one final query for both the jobCount and the jobs.

Screen_Recording_2023-06-22_at_3.31.37_PM

How to set up and validate locally

1. Enable feature flag in rails console `Feature.enable(:ci_job_failures_in_mr)
2. Make sure to have a functioning runner
3. We need a MR with jobs failures. An easy to do so is to make a merge request on the ci config file and add explicit failures
4. Navigate to Build -> Pipeline Editor
5. Change your config to include jobs failures like so:

my_failed_job:
  script: exit 1

1. Create a merge request with that change
2. Navigate to the Merge request page
3. Go to the pipelines page
4. Click on show failed jobs
5. If your pipeline is running, notice the updates
6. Click "Retry" on any job
7. Notice it updates (polling works!)
8. Retry the entire pipeline
9. Notice it polls!

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

changed milestone to %16.2

added featureenhancement frontend grouppipeline authoring typefeature labels

assigned to @f_caplette

added devopsverify sectionci labels

changed title from Add action to retry failed job in MR pipelines to Show failed jobs in MR pipelines tab part 5

marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed

added backend label

	4 Warnings
	This merge request is quite big (857 lines changed), please consider splitting it into multiple merge requests.
	featureaddition and featureenhancement merge requests normally have a documentation change. Consider adding a documentation update or confirming the documentation plan with the Technical Writer counterpart. For more information, see: The Handbook page on merge request types. The definition of done documentation.
	This merge request changed files with disabled eslint rules. Please consider fixing them.
	There were no new or modified feature flag YAML files detected in this MR. If the changes here are already controlled under an existing feature flag, please add the feature flagexists. Otherwise, if you think the changes here don't need to be under a feature flag, please add the label feature flagskipped, and add a short comment about why we skipped the feature flag. For guidance on when to use a feature flag, please see the documentation.

	1 Message
	CHANGELOG missing: If you want to create a changelog entry for GitLab FOSS, add the Changelog trailer to the commit message you want to add to the changelog. If you want to create a changelog entry for GitLab EE, also add the EE: true trailer to your commit message. If this merge request doesn't need a CHANGELOG entry, feel free to ignore this message.

Disabled eslint rules

The following files have disabled eslint rules. Please consider fixing them:

• app/assets/javascripts/merge_request_tabs.js

Run the following command for more details

node_modules/.bin/eslint --report-unused-disable-directives --no-inline-config \
  'app/assets/javascripts/merge_request_tabs.js'

Reviewer roulette

Changes that require review have been detected!

Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:

Category	Reviewer	Maintainer
backend	Lucas Charles (@theoretick) (UTC-7, 3 hours behind @f_caplette)	Roy Zwambag (@rzwambag) (UTC+2, 6 hours ahead of @f_caplette)
frontend	Deepika Guliani (@deepika.guliani) (UTC+5.5, 9.5 hours ahead of @f_caplette)	Simon Knox (@psimyn) (UTC+10, 14 hours ahead of @f_caplette)
test for spec/features/*	Lucas Charles (@theoretick) (UTC-7, 3 hours behind @f_caplette)	Maintainer review is optional for test for spec/features/*

To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.

To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.

Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

Bundle size analysis [beta]

This compares changes in bundle size for entry points between the commits 3dfc6781 and 707ac980

Special assets

Entrypoint / Name	Size before	Size after	Diff	Diff in percent
average	4.18 MB	4.18 MB	-	0.0 %
mainChunk	3.09 MB	3.09 MB	-	0.0 %

Significant Growth: 1

Expand

Entrypoint / Name	Size before	Size after	Diff	Diff in percent
pages.projects.pipelines.index	1.2 MB	1.23 MB	+25.69 KB	2.1 %

---

Your MR has at least one entrypoint growing significantly (more > 1 KB or 2%). If you write new or extend existing features, this is expected and there is nothing to worry about.

Please consider pinging someone from the FE Foundations (@leipert, @markrian, @ohoral or @pgascouvaillancourt) for review, if you are unsure about the size increase.

Note: We do not have exact data for 3dfc6781. So we have used data from: 63554dc1.
The intended commit has no webpack pipeline, so we chose the last commit with one before it.

Please look at the full report for more details

---

Read more about how this report works.

Generated by Danger

Allure report

allure-report-publisher generated test report!

e2e-test-on-gdk: test report for 707ac980

expand test summary

+------------------------------------------------------------+
|                       suites summary                       |
+-------+--------+--------+---------+-------+-------+--------+
|       | passed | failed | skipped | flaky | total | result |
+-------+--------+--------+---------+-------+-------+--------+
+-------+--------+--------+---------+-------+-------+--------+
| Total | 0      | 0      | 0       | 0     | 0     | ➖     |
+-------+--------+--------+---------+-------+-------+--------+

e2e-review-qa: test report for 707ac980

expand test summary

+-----------------------------------------------------------------------+
|                            suites summary                             |
+------------------+--------+--------+---------+-------+-------+--------+
|                  | passed | failed | skipped | flaky | total | result |
+------------------+--------+--------+---------+-------+-------+--------+
| Create           | 8      | 0      | 1       | 1     | 9     | ❗     |
| Verify           | 10     | 0      | 0       | 0     | 10    | ✅     |
| Govern           | 2      | 0      | 0       | 0     | 2     | ✅     |
| Plan             | 3      | 0      | 1       | 0     | 4     | ✅     |
| Manage           | 1      | 0      | 0       | 0     | 1     | ✅     |
| Data Stores      | 2      | 0      | 0       | 0     | 2     | ✅     |
| Monitor          | 4      | 0      | 0       | 0     | 4     | ✅     |
| Framework sanity | 0      | 0      | 1       | 0     | 1     | ➖     |
+------------------+--------+--------+---------+-------+-------+--------+
| Total            | 30     | 0      | 3       | 1     | 33    | ❗     |
+------------------+--------+--------+---------+-------+-------+--------+

Setting label(s) Category:Pipeline Composition based on grouppipeline authoring.

added Category:Pipeline Composition label

added 1 commit

• e8c8bdb8 - Add polling to the failures job widget

Compare with previous version

added 720 commits

• e8c8bdb8...c23ca879 - 719 commits from branch master
• ade4b811 - Add polling to the failures job widget

Compare with previous version

changed the description

added 1 commit

• 041c8021 - Add polling to the failures job widget

Compare with previous version

changed the description

added UX label

Please wait for Reviewer Roulette to suggest a designer for UX review, and then assign them as Reviewer. This helps evenly distribute reviews across UX.

This message was generated automatically. You're welcome to improve it.

added 371 commits

• 041c8021...e5348b5a - 370 commits from branch master
• 6ebfd082 - Add polling to the failures job widget

Compare with previous version

@lma-git Could you do the initial backend review here? This is for the failed jobs widget, thanks!

@treagitlab Could you do the test review here? I have a question for you about some interesting behaviour!

@slashmanov Could you do the initial frontend review? This is the last part of the failed jobs widget. When everything looks good on your side, please pass to ntepluhina, thanks!

Note to all reviewers: This looks way bigger than it is. There is a lot of moved and renamed files and the diff is more around ~500+-. It made little sense to ship part of the polling and not everything, so I do beleive this is the smallest step, thanks!

requested review from @slashmanov, @lma-git, and @treagitlab

approved this merge request

@lma-git, thanks for approving this merge request.

This is the first time the merge request is approved. To ensure full test coverage, a new pipeline will be started shortly.

For more info, please refer to the following links:

• rspec predictive jobs
• jest predictive jobs
• merging a merge request.

added pipeline:mr-approved label

The backend changes LGTM. Hi @drew! Could you please do the backend and ~"Verify" maintainer review here? Thank you!

requested review from @drew

approved this merge request

removed review request for @drew

resolved all threads

@f_caplette per our discovery earlier. We ran into the infinite polling when a new pipeline is triggered (e.g. user push a new commit to the MR)

added 1 commit

• db516388 - Fix polling issues

Compare with previous version

requested review from @bsandlin and removed review request for @slashmanov

approved this merge request

unapproved this merge request

added 1 commit

• 41393c26 - Remove unused attribute from spec

Compare with previous version

approved this merge request

@f_caplette code lgtm, just found the one issue with polling! Back to you

removed review request for @lma-git

added 1 commit

• 707ac980 - Fix polling issue in failed jobs list

Compare with previous version

approved this merge request

requested review from @cngo and removed review request for @bsandlin

requested review from @ntepluhina and removed review request for @cngo

resolved all threads

approved this merge request

removed review request for @ntepluhina

@drew Seems like we lost your approval here. Could you re-approve and set this to merge? Thanks!

requested review from @drew

removed review request for @treagitlab

approved this merge request

resolved all threads

enabled an automatic merge when the pipeline for f73acb6c succeeds

resolved all threads

merged

mentioned in commit 99f29d56

mentioned in merge request !125926 (merged)

added workflowstaging-canary label

added workflowcanary label and removed workflowstaging-canary label

added workflowstaging label and removed workflowcanary label

added workflowproduction label and removed workflowstaging label

added releasedcandidate label

added releasedpublished label and removed releasedcandidate label