Update frontend to use retryPath for deployment redeploy/rollback

What does this MR do and why?

This MR updates the frontend to use a new retryPathfield added in !199602 (merged). It also removes the rollback/retry button if the job is not retryable.

This MR uses the new directive @gl_introduced and fallbacks to the old way of calculating the URL from webPath. We can remove the fallback in %18.4.

References

Screenshots or screen recordings

Before After
Screenshot_2025-07-30_at_13.17.18 Screenshot_2025-07-30_at_13.07.37
Screen_Recording_2025-07-30_at_13.17.21 Screen_Recording_2025-07-30_at_13.08.01

How to set up and validate locally

  1. Add a .gitlab-ci.yml file to the repository. Example to create an environment with some deployments:
stages:
  - deploy

variables:
  DEPLOY_MESSAGE: "Simple deployment test"

deploy-job:
  stage: deploy
  image: alpine:latest
  script:
    - "echo 'Starting deployment...'"
    - "echo 'Deploy message: $DEPLOY_MESSAGE'"
    - "sleep 5"
    - "echo 'Deployment completed successfully'"
  environment:
    name: test-env
    url: https://test-example.com
  when: manual

deploy-job-2:
  stage: deploy
  image: alpine:latest
  script:
    - "echo 'Second deployment job'"
    - "sleep 3" 
    - "echo 'Second job completed'"
  environment:
    name: test-env-2
    url: https://test2-example.com
  when: manual
  1. Run the pipeline
  2. Visit Operate -> Environments
  3. Try to redeploy/rollback a deployment
  4. Validate the action is only available if the related job is retryable and the user has permissions to retry.
  5. Validate the action performs successfully

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #556036 (closed)

Edited by Anna Vovchenko

Merge request reports

Loading