Runner.Server

The implementation of Container Hooks provides the following capabilities for self-hosted runners:

• Non-Docker Scenarios: The runner supports non-Docker environments for self-hosted runners, allowing administrators to customize their Docker invocations.
• Documentation and Examples: Official documentation and an open-source repository containing examples are provided for managing Docker hooks.
• Telemetry: The system includes telemetry specifically designed to troubleshoot support issues related to these hooks.

The runner does not use the node executable found in your system $PATH. Instead, it uses its own built-in copies of Node.js located within the runner root directory. JavaScript-based Actions are executed using these specific versions based on the version requested in the action's metadata.

Node.js locations:

• <runner_root>/externals/node20/
• <runner_root>/externals/node24/

The Git Connection Check ensures that the git executable can successfully access GitHub.com or your GitHub Enterprise Server. The check is performed by executing git ls-remote against a known repository. To assist in debugging, the runner sets the environment variables GIT_TRACE=1 and GIT_CURL_VERBOSE=1 during this check, which forces git to produce detailed debug logs.

# For GitHub.com
git ls-remote --exit-code https://github.com/actions/checkout HEAD

# For GitHub Enterprise Server
git ls-remote --exit-code https://ghes.me/actions/checkout HEAD

The runner configuration allows you to explicitly register "built-in" labels (such as ubuntu-latest) as custom labels. This is a valid operation and is not treated as an error.

This pattern is useful for administrators who want to enforce specific runner sets via policy without requiring users to update all existing workflow files.

To support conditionals within composite actions, a new field action_status is available in the GitHub context. This field mimics the job context status but specifically tracks the status of the current composite action.

• Purpose: Allows main steps within a composite action to use functions like success() to check if the current composite action is still in a successful state.
• Scope: This field is specifically relevant for composite actions. In a regular workflow, success() checks the job_status. In a composite action's main step, success() checks if action_status == success.

Container Hooks are high-level abstractions that map to runner actions rather than specific low-level container commands (like docker build). This design allows the runner to be extensible and flexible, supporting different environments like Docker or Kubernetes without forcing users to implement a large number of low-level hooks.

Instead of mirroring every container lifecycle event, the runner provides a few key hooks that represent major job phases. This approach simplifies the implementation for users and allows the runner to manage state (like container IDs) internally, which is particularly useful for environments like Kubernetes where traditional container IDs might not be the primary way to interact with workloads.

The runner sends a JSON object to your hook handler via stdin. This object contains the command to execute, the arguments, and a state object for persistence.

Input Fields:

• command: The specific hook command the runner expects you to invoke.
• responseFile: The file path where you must write your output (if the command requires returning data).
• args: A JSON object containing specific arguments for the command.
• state: A JSON object used to maintain state across different hook invocations.

{
  "command": "job_cleanup",
  "responseFile": "/users/thboop/runner/_work/{guid}.json",
  "args": {},
  "state": 
  {
      "id": "82e8219701fe096a35941d869cf8d71af1d943b5d3bdd718850fb87ac3042480"
  }
}

When using Container Hooks in the runner, be aware of the following constraints:

• OS Support: Hooks currently only support Linux on launch.
• Configuration Scope: Hooks are configured by the runner admin. Consequently, they are only supported on self-hosted runners, not GitHub-hosted runners.

Multi-line matchers are used when an error spans multiple lines (e.g., a header line containing the filename followed by several error lines).

To implement this, provide an array of patterns in the pattern property. The last pattern in the array can include a "loop": true property, which tells the engine to continue searching for more matches using that pattern.

Example: ESLint Stylish Mode

In this pattern, the first regex captures the filename, and the second regex (with loop: true) captures the individual error details.

{
  "owner": "eslint-stylish",
  "pattern": [
    {
      "regexp": "^([^\\s].*)$",
      "file": 1
    },
    {
      "regexp": "^\\s+(\\d+):(\\d+)\\s+(error|warning|info)\\s+(.*)\\s\\s+(.*)$",
      "line": 1,
      "column": 2,
      "severity": 3,
      "message": 4,
      "code": 5,
      "loop": true
    }
  ]
}