handle the /support command workflow (kubernetes/kubeadm)

The handle the /support command workflow from kubernetes/kubeadm, explained and optimized by Latchkey.

Source: kubernetes/kubeadm.github/workflows/support-command.yamlLicense Apache-2.0View source

A: CI health grade
85/100: Health score
1: Job per trigger
2: Fixes in the optimized version

In short

CI health: A (excellent)
The optimized version below points runs-on at Latchkey managed runners and adds job timeouts.

What it does

This is the handle the /support command workflow from the kubernetes/kubeadm repository, a real project running GitHub Actions. It is shown here with attribution under its Apache-2.0 license.

Below, Latchkey shows a faster, safer version produced by its optimization engine.

The workflow

workflow (.yml)

on: issue_comment
name: handle the /support command
permissions: {}
jobs:
  support_comment:
    permissions:
      issues: write

    runs-on: ubuntu-24.04
    steps:
      - name: check for the /support command
        id: command
        uses: xt0rted/slash-command-action@bf51f8f5f4ea3d58abc7eca58f77104182b23e88 # v2.0.0
        continue-on-error: true
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          command: support
          reaction: "false"
          allow-edits: "true"
          permission-level: admin
      - name: comment with support text
        if: steps.command.outputs.command-name
        uses: ben-z/actions-comment-on-issue@402eb412a8f396be0d4ac52a823ec7121206cc26 # 1.0.3
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          message: |
            Hello, @${{ github.event.issue.user.login }} :wave: :robot:

            You seem to have troubles using Kubernetes and kubeadm.
            Note that our issue trackers **should not** be used for providing support to users.
            There are special channels for that purpose.

            Please see:
            - https://github.com/kubernetes/kubeadm#support
      - name: add support label
        if: steps.command.outputs.command-name
        uses: actions-ecosystem/action-add-labels@18f1af5e3544586314bbe15c0273249c770b2daf # v1.1.3
        with:
          labels: kind/support
      - name: close issue
        if: steps.command.outputs.command-name
        uses: peter-evans/close-issue@a700eac5bf2a1c7a8cb6da0c13f93ed96fd53dbe # v1.0.3

The same workflow, on Latchkey

Removes redundant runs and caps runaway jobs. Added and changed lines are highlighted.

workflow (.yml), optimized

on: issue_comment
name: handle the /support command
permissions: {}
jobs:
  support_comment:
    timeout-minutes: 30
    permissions:
      issues: write

    runs-on: ubuntu-24.04
    runs-on: latchkey-small
    steps:
      - name: check for the /support command
        id: command
        uses: xt0rted/slash-command-action@bf51f8f5f4ea3d58abc7eca58f77104182b23e88 # v2.0.0
        continue-on-error: true
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          command: support
          reaction: "false"
          allow-edits: "true"
          permission-level: admin
      - name: comment with support text
        if: steps.command.outputs.command-name
        uses: ben-z/actions-comment-on-issue@402eb412a8f396be0d4ac52a823ec7121206cc26 # 1.0.3
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          message: |
            Hello, @${{ github.event.issue.user.login }} :wave: :robot:

            You seem to have troubles using Kubernetes and kubeadm.
            Note that our issue trackers **should not** be used for providing support to users.
            There are special channels for that purpose.

            Please see:
            - https://github.com/kubernetes/kubeadm#support
      - name: add support label
        if: steps.command.outputs.command-name
        uses: actions-ecosystem/action-add-labels@18f1af5e3544586314bbe15c0273249c770b2daf # v1.1.3
        with:
          labels: kind/support
      - name: close issue
        if: steps.command.outputs.command-name
        uses: peter-evans/close-issue@a700eac5bf2a1c7a8cb6da0c13f93ed96fd53dbe # v1.0.3

What changed

Run on Latchkey managed runners with one line (runs-on), which apply the fixes below automatically and self-heal transient failures. Each Linux x64 job moves to the Latchkey size matching its vCPU count, latchkey-small for a standard 2 vCPU runner; macOS, Windows and arm64 jobs stay as written.
Add a job timeout so a hung step cannot burn hours of runner time.

This workflow runs 1 job per trigger. It runs on a standard GitHub-hosted Linux x64 runner, which in a private repository bills $0.006 a minute against $0.0025 on latchkey-small, 58% lower; in a public repository like this one it is free. Estimate the monthly difference with your own run counts.

Actions used in this workflow

xt0rted/slash-command-action
ben-z/actions-comment-on-issue
actions-ecosystem/action-add-labels
peter-evans/close-issue

Frequently asked questions

What does the handle the /support command workflow (kubernetes/kubeadm) workflow do?

This is the handle the /support command workflow from the kubernetes/kubeadm repository, a real project running GitHub Actions. It is shown here with attribution under its Apache-2.0 license.

What CI health grade does this workflow get?

This Automation and other workflow grades A. Paste your own workflow into the Latchkey grader to see its grade and the exact fixes.

How can I improve this Automation and other workflow?

Add job timeouts. Latchkey applies these automatically on managed runners when you point runs-on at Latchkey.

References

GitHub Actions documentation