Objective

A repository at /home/interview/repo has a deployment workflow that occasionally hangs due to network issues or unresponsive external services. Jobs need to be automatically terminated if they exceed a time limit.

Task

Complete the workflow at .github/workflows/deploy.yml that triggers on push events. The deploy job should check out the code and run ./scripts/long-running-task.sh with a step-level timeout of 2 minutes using timeout-minutes: 2 on the run step.

File Path

• Workflow: /home/interview/repo/.github/workflows/deploy.yml
• Script: /home/interview/repo/scripts/long-running-task.sh

name: Deploy with Timeout

on:
  push:

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run long-running task
        timeout-minutes: 2
        run: ./scripts/long-running-task.sh

Explanation

Step 1: Step-Level Timeout

- name: Run long-running task
  timeout-minutes: 2
  run: ./scripts/long-running-task.sh

timeout-minutes: 2 is placed on the step itself. This sets a 2-minute maximum for this specific step. If the script hasn't finished within 2 minutes, GitHub Actions cancels it and marks the step as failed. This is useful when we know which step is likely to hang.

Note: Job-Level vs Step-Level

timeout-minutes can also be placed at the job level (next to runs-on), which applies to all steps combined. Step-level is more precise because it targets the specific step that might hang, while the other steps (like checkout) aren't affected by the limit.