Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • See what's new at GitLab
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab FOSS
GitLab FOSS
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 5
    • Merge Requests 5
  • Requirements
    • Requirements
    • List
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Merge Requests
  • !17814

Merged
Opened Mar 16, 2018 by Mayra Cabrera@mayra-cabrera🎄Maintainer9 of 13 tasks completed9/13 tasks

Resolve "Show `failure_reason` in jobs view content section"

  • Overview 89
  • Commits 22
  • Pipelines 31
  • Changes 20

What does this MR do?

Part of https://gitlab.com/gitlab-org/gitlab-ce/issues/41111. Displays a verbose failure reason on Job detail page: root/minimal-ruby-app-test/-/jobs/23

Are there points in the code the reviewer needs to double check?

The HAML part that was removed included some permissions check.

After following the stack on the API ruby code, those permissions seem to be checked to expose the retry_path, so the frontend is relying on retry_path to know if user is authorised.The HAML part that was removed included some permissions check.

~~After following the stack on the API ruby code, those permissions seem to be checked to expose the retry_path, so the frontend is relying on retry_path to know if user is authorised.~~~ ^ Fixed.

Why was this MR needed?

Currently when a job fails, we have no direct way to know which is the problem. The only option is to look at job details and read the output log, where we can possibly see some error message. This MR display the error on the job detail page

Screenshots (if relevant)

For failed job

Screen_Shot_2018-04-01_at_1.09.30_PM

For an allowed to fail job

Screen_Shot_2018-04-01_at_1.09.20_PM

For a job with no log

Screen_Shot_2018-04-01_at_1.25.21_PM

When retry button is not primary

Screen_Shot_2018-04-13_at_12.41.28_PM

Does this MR meet the acceptance criteria?

  • Changelog entry added, if necessary
  • Tests added for this feature/bug
  • Documentation created/updated
  • Review
    • Has been reviewed by UX
    • Has been reviewed by Frontend
    • Has been reviewed by Backend
  • Conform by the merge request performance guides
  • Conform by the style guides
  • Squashed related commits together
  • End-to-end tests pass (package-qa manual pipeline job)

What are the relevant issue numbers?

Closes #44271 (closed)

To do

Implement the following tasks:

  • Display failure message frontend
  • Transform 'retry' button to primary button if needed frontend
  • Display 'No job log' statement, if there's no job log. backend
Edited Apr 19, 2018 by Grzegorz Bizon
Assignee
Assign to
Reviewer
Request review from
10.8
Milestone
10.8 (Past due)
Assign milestone
Time tracking
Reference: gitlab-org/gitlab-foss!17814
Source branch: 44271-show-failure-reason-in-job-views-content-section

Revert this merge request

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this merge request

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.