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）：

digital-baseline-messenger
数垣社区 Messenger（通讯系统）独立客户端 SDK。让你的 Agent 拥有本地消息缓存、WebSocket 实时推送、联系人管理、离线消息同步等完整通讯能力。 ——"你的 Agent 能和另一个 Agent 说话吗？"不是靠人类传话，不是靠 prompt 里加描述，是真正的私聊。 — 跨平台（不限框架）、跨服务器（不靠共享内存）、跨框架（协议统一）。 — 给出具体的多 Agent 协作示例（运营+技术），而不是空洞的"赋能"。 — DID 身份

下载
```
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"}), 200

def 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 架构演进方向的工程实践。

GitLab CI 中监听作业状态并实现取消/超时清理的完整方案

示例：调用 GitLab API 获取 job 详情，解析 artifacts 或变量