Gitlab CI部署状态报告至REST API的配置问题咨询

Hey there! Let's tackle those two GitLab CI issues you're facing step by step. Here's how to adjust your configuration to fix both problems while keeping the report-deployment job reusable across projects:

Problem 1: Pipeline hangs when deploy isn't manually triggered #

The needs: ["deploy"] directive forces report-deployment to wait indefinitely for the manual deploy job if it's never triggered. We can fix this by making the dependency optional and only running the report job when deployment status files exist.

Problem 2: Only one report sent for multiple deploy triggers #

When you manually run deploy multiple times, the single deployment-status file gets overwritten, so only the last status is reported. We'll generate unique status files per job to ensure every deployment attempt sends a separate report.

Updated GitLab CI Configuration #

deploy:
  stage: deploy
  image: $IMAGE1
  script:
    # Set up error trapping to capture deployment failures
    - trap 'echo "Failed" > deployment-status-${CI_JOB_ID}' ERR
    # Replace the line below with your actual deployment code
    - cd ${CI_PROJECT_DIR} && echo "Running deployment..."
    # If deployment succeeds, write success status
    - echo 'Passed' > deployment-status-${CI_JOB_ID}
  when: manual
  artifacts:
    when: always
    paths:
      - deployment-status-*  # Capture all unique status files

report-deployment:
  stage: post-deploy
  image: $IMAGE2
  script:
    # Loop through all unique status files and send each to your API
    - for status_file in deployment-status-*; do
        DEPLOY_STATUS=$(cat "$status_file");
        DEPLOY_JOB_ID="${status_file#deployment-status-}"
        # Replace with your actual REST API call (example using curl)
        # curl -X POST \
        #   -H "Content-Type: application/json" \
        #   -d '{"status": "'"$DEPLOY_STATUS"'", "job_id": "'"$DEPLOY_JOB_ID"'", "project": "'"$CI_PROJECT_NAME"'"}' \
        #   https://your-api-endpoint.com/deployment-status
        echo "Reported status: $DEPLOY_STATUS for job ID $DEPLOY_JOB_ID"
      done
  when: always
  needs:
    - job: deploy
      optional: true  # Don't wait if deploy wasn't triggered
  rules:
    - exists:
        - deployment-status-*  # Only run if status files exist

Key Changes Explained #

1. Unique Status Files:

   • We use $CI_JOB_ID (a unique identifier for each job run) to name our status files (deployment-status-${CI_JOB_ID}). This ensures every manual deploy trigger creates a distinct file instead of overwriting the old one.
   • The artifacts path is updated to deployment-status-* to capture all these unique files.

2. Avoid Hanging Pipelines:

   • needs: [{job: "deploy", optional: true}] tells GitLab not to wait for deploy if it wasn't triggered.
   • The rules: exists condition ensures report-deployment only runs when there are status files to process—if deploy was never triggered, this job is skipped entirely, and the pipeline completes normally.

3. Robust Error Handling:

   • The trap command ensures that if the deployment fails (and exits with a non-zero code), we still write a Failed status file. This guarantees we always have a status to report, even when deployments go wrong.

内容的提问来源于stack exchange，提问作者Hamidreza