嗨，针对你遇到的「测试步骤超时时无法触发通知」的问题，GitHub Actions本身确实没有直接提供判断特定步骤超时的内置变量，也没有现成的环境变量可以直接获取作业启动后的耗时，但有几个非常简便的方案能帮你实现需求：

方案1：用timeout命令强制控制超时并捕获状态 #

这是最直接也最可靠的方式——把你的测试命令用系统的timeout命令包裹起来。当测试命令超时后，timeout会返回固定的退出码（通常是124），后续步骤就能通过这个退出码精准判断是否是超时导致的失败。

给你一个实际的配置示例：

jobs:
  test-suite:
    runs-on: ubuntu-latest
    steps:
      - name: 执行自动化测试（设置10分钟超时）
        id: test_run
        run: timeout --signal=SIGKILL 10m npm run test  # 替换成你的测试命令
        continue-on-error: true  # 允许步骤失败，保证后续通知步骤能执行

      - name: 发送超时专属通知
        if: steps.test_run.outcome == 'failure' && steps.test_run.outputs.exit_code == 124
        run: |
          # 这里写入你的通知逻辑，比如调用企业微信/邮件API
          echo "⚠️ 测试步骤超时，已触发通知"

小提示：不同操作系统的timeout参数略有差异——Linux环境直接用timeout，macOS需要先安装coreutils（brew install coreutils），然后用gtimeout替代。另外一定要加上continue-on-error: true，否则步骤失败后整个作业会直接终止，通知步骤根本没机会执行。

方案2：利用作业级超时配合状态判断 #

如果你的测试步骤是整个作业的核心环节，也可以给整个作业设置超时时间，然后通过作业的状态来判断是否超时。当作业因为超时而被GitHub终止时，你可以通过cancelled()函数结合步骤的执行状态来触发通知：

示例配置：

jobs:
  test-suite:
    runs-on: ubuntu-latest
    timeout-minutes: 15  # 整个作业的超时阈值
    steps:
      - name: 执行自动化测试
        id: test_run
        run: npm run test

      - name: 发送作业超时通知
        if: cancelled() && steps.test_run.outcome == 'started'
        run: |
          echo "⚠️ 测试作业超时，已触发通知"

这个方案的局限性是：它只能判断整个作业是否超时，无法精准定位到某个特定步骤，适合测试步骤是作业中唯一可能超时的场景。

关于作业耗时的环境变量 #

遗憾的是，GitHub Actions目前没有提供现成的环境变量来直接获取作业或步骤的耗时。你提到的自定义变量记录起止时间确实可行，但相比之下，上面的timeout方案更简便，不需要手动处理时间计算，完全依赖命令本身的退出状态就能完成判断。

总结一下：最推荐用方案1，既能精准检测特定步骤的超时情况，又不需要额外的时间记录逻辑，完全符合你想要的简便实现方式。

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