GitLab 17.0 起 after_script 将原生支持在作业被手动取消或超时时执行，此前可借助 Webhook 监听 job 事件实现外部清理逻辑，避免资源泄漏。
gitlab 17.0 起 `after_script` 将原生支持在作业被手动取消或超时时执行，此前可借助 webhook 监听 job 事件实现外部清理逻辑，避免资源泄漏。
在 GitLab CI/CD 流水线中，作业（job）可能因超时、手动取消或 runner 异常中断而提前终止。此时，常规的 after_script 不会执行——这导致数据库连接未关闭、临时文件未清理、后台进程未终止等资源泄漏问题。虽然 GitLab 社区长期呼吁该能力（Epic #10158），但直到 GitLab 17.0（2024年5月发布） 才正式落地：after_script 将统一在所有终止场景（success / failure / canceled / timeout）下运行。
✅ 升级至 GitLab 17.0 后的推荐做法（简洁可靠）：
直接在 .gitlab-ci.yml 中定义健壮的 after_script，并确保其具备幂等性与异常容错能力：
job_with_cleanup:
script:
- echo "Starting long-running task..."
- python3 start_server.py &
- SERVER_PID=$!
- sleep 60 # Simulate work
after_script:
- echo "Running cleanup for job: $CI_JOB_NAME (status: $CI_JOB_STATUS)"
- kill "$SERVER_PID" 2>/dev/null || true
- rm -f /tmp/myapp.lock /tmp/*.log
- echo "Cleanup completed."⚠️ 注意事项：
- $CI_JOB_STATUS 在 after_script 中始终可用，值为 success、failed、canceled 或 timeout；
- 使用 || true 或 set +e 避免 cleanup 失败导致整个 job 状态误判；
- 若需清理跨节点资源（如云服务实例、远程容器），建议将清理逻辑封装为幂等 API，并在 after_script 中调用。
? GitLab
当无法立即升级时，可通过 Project Webhook 接收实时 job 事件，在外部服务中触发清理：
启用 Job Events Webhook（项目 → Settings → Integrations）：
URL: https://your-cleanup-service.example.com/webhook
勾选 ✅ Job events，并启用 Enable SSL verification（生产环境必需）。-
服务端示例（Python + Flask）：
from flask import Flask, request, jsonify import logging
app = Flask(name) logging.basicConfig(level=logging.INFO)
@app.route('/webhook', methods=['POST']) def handle_job_event(): event = request.headers.get('X-Gitlab-Event') payload = request.get_json()
if event == 'Job Hook' and payload.get('status') in ['canceled', 'timeout']:
job_id = payload['id']
project_id = payload['project_id']
runner = payload.get('runner', {}).get('description', 'unknown')
logging.info(f"Triggering cleanup for canceled/timed-out job #{job_id} in project {project_id} (runner: {runner})")
# ✅ 这里调用你的清理逻辑：kill 进程、释放锁、销毁临时环境等
cleanup_resources(job_id, project_id)
return jsonify({"status": "cleanup_scheduled"}), 202
return jsonify({"status": "ignored"}), 200def cleanup_resources(job_id: int, project_id: int):
示例：调用 GitLab API 获取 job 详情，解析 artifacts 或变量
# 或根据 job_id 查询本地 runner 日志/进程表，执行 kill -9 / rm -rf pass
if name == 'main': app.run(host='0.0.0.0:8000')
? **关键提醒：** - Webhook 方案需自行保障服务高可用与重试机制（GitLab 默认重试 3 次，HTTP 5xx 错误触发）； - 敏感操作（如删除生产数据）建议加入人工确认钩子或审批队列； - 避免在 Webhook 处理中执行耗时操作，应转为异步任务（如 Celery/RQ）。 总之，GitLab 17.0 是分水岭：优先升级以获得开箱即用的 `after_script` 可靠性；若暂不可行，则 Webhook + 轻量监听服务是成熟、解耦且符合 GitLab 架构演进方向的工程实践。
