This is a followup from the discussion in this thread https://gitlab.com/groups/gitlab-org/-/epics/8516#note_1173353507 > I feel like we should have a way to force a re-check without having to make a change. Like a button beside the check to re-run the check. We currently use something like that for site validation for DAST profiles. As a first iteration, that would make this a lot more useable when the checks are blocking an MR. > Yes, we will need backend work. Outside of the 3 actions mentioned [in the doc](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html), we currently have no way of triggering the webhook that informs the external service to run a check, so we need a new API endpoint for it. > Here is the [figma link to the designs](https://www.figma.com/file/zqEjEpLS0ggRsbUdzDrWkj/Retry-button-%5BGovern%2FCompliance%23383200%5D?node-id=24%3A7586&t=fyH8him9zvfP4o7n-1) > Regarding the `Retry` button, we'll need to work with Foundations to make sure we're using the merge report framework correctly. For example, would you expect to see `Retry` on each individual failed check (the `GitBot` example [posted above](https://gitlab.com/groups/gitlab-org/-/epics/8516#note_1175253079)), or should it only be on the top level (ie 2 failed status checks - Retry all failed checks) ~backend Create an API to retry the failed status check. ## Purposed Implementation Plan weight: :two: 1. Create post api `/api/v4/projects/:id/merge_requests/:merge_request_iid/status_checks/:check_id/retry` ###### Example curl ```bash curl --location --request POST 'curl --location --request POST 'http://BASE_URL//api/v4/projects/6/merge_requests/4/status_checks/1/retry' \ --header 'Authorization: ACCESS_TOKEN' \ --data-raw ''' ``` 2. User `merge_request.to_hook_data(current_user)` to generate current state payload 3. Async post this data payload to status checks url 4. Write Specs ~frontend A button to call the retry API from the MR widget