install more tools, more guidelines

Author: theihor

.github/scripts/download-gcc-bpf.sh

@@ -7,18 +7,7 @@ INSTALL_DIR=$(realpath $2)
 
 cd /tmp
 
-if ! command -v gh &> /dev/null; then
-    # https://github.com/cli/cli/blob/trunk/docs/install_linux.md
-    (type -p wget >/dev/null || (sudo apt update && sudo apt install wget -y)) \
-	&& sudo mkdir -p -m 755 /etc/apt/keyrings \
-	&& out=$(mktemp) && wget -nv -O$out https://cli.github.com/packages/githubcli-archive-keyring.gpg \
-	&& cat $out | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
-	&& sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
-	&& sudo mkdir -p -m 755 /etc/apt/sources.list.d \
-	&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
-	&& sudo apt update \
-	&& sudo apt install gh -y
-fi
+$(dirname $0)/install-github-cli.sh
 
 tag=$(gh release list -L 1 -R ${GCC_BPF_RELEASE_GH_REPO} --json tagName -q .[].tagName)
 if [[ -z "$tag" ]]; then

.github/scripts/install-github-cli.sh

@@ -0,0 +1,16 @@
+#!/bin/bash
+
+set -euo pipefail
+
+if ! command -v gh &> /dev/null; then
+    # https://github.com/cli/cli/blob/trunk/docs/install_linux.md
+    (type -p wget >/dev/null || (sudo apt update && sudo apt install wget -y)) \
+	&& sudo mkdir -p -m 755 /etc/apt/keyrings \
+	&& out=$(mktemp) && wget -nv -O$out https://cli.github.com/packages/githubcli-archive-keyring.gpg \
+	&& cat $out | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
+	&& sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
+	&& sudo mkdir -p -m 755 /etc/apt/sources.list.d \
+	&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
+	&& sudo apt update \
+	&& sudo apt install gh -y
+fi

.github/workflows/ai-agent.yml

@@ -121,6 +121,17 @@ jobs:
           restore-keys: |
             notes-md-${{ github.repository }}-
 
+      - name: Install misc tools
+        shell: bash
+        env:
+          GCC_VERSION: 14
+          LLVM_VERSION: 19
+        run: |
+          sudo apt-get update -y
+          ${{ github.workspace }}/.github/scripts/install-github-cli.sh
+          ${{ github.workspace }}/ci/kernel-patches/runner/install-dependencies.sh all
+          sudo apt-get install python3 jq
+
       - uses: anthropics/claude-code-action@v1
         with:
           show_full_output: true
@@ -143,6 +154,12 @@ jobs:
           name: output
           path: output/
 
+      - name: Copy NOTES.md to the output
+        shell: bash
+        run: |
+          mkdir -p output
+          cp NOTES.md output/NOTES.md
+
       - name: Save NOTES.md to cache
         if: always()
         uses: actions/cache/save@v5

ci/claude/bpf-ci-agent.md

@@ -19,21 +19,36 @@ You have access to:
 - `dependencies` directory with the source code of various tools used
   in the CI testing
 - BPF CI worklow job logs accessible via GitHub
+  - You should have access to github cli (gh) and github tools via MCP
+  - BPF CI workflows run in kernel-patches/bpf GitHub repository
 - Your own notes stored in NOTES.md from the previous runs
 
 ## Guidelines
 
 Your exploration should be driven by these principles:
-- Long term impact: will addressing a particular issue solve an actual
-  problem Linux Kernel developers and users care about?
-- Human-prompted: was this issue ever brought up on the mailing list
-  or in commit messages by developers? If yes, it's likely worth
-  investigating.
-- Better signal-to-noise ratio
+- Focus on testing quality and coverage. Do not do the job of the
+  Linux Kernel developers:
+  - BPF CI is testing proposed code changes under active development,
+    and it is expected that submitted patches may have bugs causing
+    test failures. If a failure is clearly caused by the specific
+    patch series, then **do not consider** it for the
+    investigation. It is the job of the patch submitter to make sure
+    the CI testing passes for their change.
+  - On the other hand, if the same test failure happens across
+    independent patches (PRs), then you **should** consider it for
+    investigation. Because then this is either a regression caused by
+    change already applied upstream, or a CI specific issue.
+- Long term impact: will addressing the issue solve an actual problem
+  Linux Kernel developers and users care about?
+- Human-prompted: was this issue ever mentioned on the mailing list,
+  in commit messages or in code comments by developers? If yes, it's
+  likely worth investigating.
+- Better signal-to-noise ratio:
   - Is this issue flaky? Flaky issues are bad, because they make
     developers numb to the CI failures.
   - Is this issue caused by an external dependency? If a failure was
-    caused by a github outage, it's not worth investigating.
+    caused by a github outage, for example, then it's not worth
+    investigating.
 
 You are free to use the existing CI scripts and Linux code, and write,
 compile and run your own code to investigate, experiment and test.