Repository navigation
ci: bring back GitHub Actions test workflow - #170
Conversation
Signed-off-by: Denis Ollier <dollierp@redhat.com>
kubevirt-prow
Bot
added
dco-signoff: yes
📝 WalkthroughWalkthroughAdds a pull request GitHub Actions workflow that runs ChangesGo test workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant PullRequest
participant GitHubActions
participant Repository
participant GoTest
PullRequest->>GitHubActions: Trigger ci-health-tests for matching paths
GitHubActions->>Repository: Checkout repository
GitHubActions->>GitHubActions: Write secrets.GITHUB_TOKEN to /run/github-token
GitHubActions->>GoTest: Run go test ./...
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8).github/workflows/ci-health-tests.yamlTraceback (most recent call last): Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/ci-health-tests.yaml (1)
20-22: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winDisable implicit checkout credential persistence.
actions/checkoutpersists credentials by default, while this job already writes the token explicitly for the tests. Disable the redundant credential path, especially before executing pull-request code. (github.com)Suggested change
- name: Checkout Git repository id: checkout uses: actions/checkout@v6 + with: + persist-credentials: false🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci-health-tests.yaml around lines 20 - 22, Update the actions/checkout step identified by id checkout to disable persisted credentials by setting its persist-credentials input to false, while leaving the existing explicit token setup unchanged.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci-health-tests.yaml:
- Around line 12-13: Add the pull-requests: read permission alongside contents:
read in the workflow’s top-level permissions block so GITHUB_TOKEN can access
pull request metadata during the Go test suite, while preserving the existing
minimal permissions.
In `@README.md`:
- Line 143: Update the workflow table entry for ci-health-tests.yaml: correct
the filename extension from .yml to .yaml and revise the trigger description to
include changes under .github/** in addition to Go-code modifications.
---
Nitpick comments:
In @.github/workflows/ci-health-tests.yaml:
- Around line 20-22: Update the actions/checkout step identified by id checkout
to disable persisted credentials by setting its persist-credentials input to
false, while leaving the existing explicit token setup unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 98556985-60be-4396-b033-3b8e61721962
📒 Files selected for processing (2)
.github/workflows/ci-health-tests.yamlREADME.md
| permissions: | ||
| contents: read |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
rg -n 'githubv4|api.github.com|GITHUB_TOKEN_PATH|TokenPath' cmd e2e pkgRepository: kubevirt/ci-health
Length of output: 1539
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow =="
cat -n .github/workflows/ci-health-tests.yaml | sed -n '1,180p'
echo "== gh client implementation =="
cat -n pkg/gh/main.go | sed -n '1,230p'
echo "== runner options/tests and token usages =="
rg -n 'NewClient|GITHUB_TOKEN|GITHUB_TOKEN_PATH|tokenPath|TokenPath|api\.github\.com|GitHubClient|Do' pkg cmd e2e --glob '*.go'Repository: kubevirt/ci-health
Length of output: 13997
🌐 Web query:
GitHub Actions permissions on pull_request forks GITHUB_TOKEN contents read GitHub Actions permissions documentation
💡 Result:
GitHub Actions enforces strict security boundaries for workflows triggered by pull requests from forked repositories to prevent unauthorized access to sensitive resources [1][2][3]. Standard pull request events (such as pull_request and pull_request_review) are considered untrusted when they originate from a fork [1][3]. Consequently, the GITHUB_TOKEN granted to these workflows is automatically restricted to read-only permissions, regardless of any permissions settings defined in the workflow file [4][5][6][7]. Additionally, these workflows are denied access to repository and organization secrets [1][2][8]. The pull_request_target event is the primary exception to this restriction [4][5]. Because this event runs the workflow code from the base repository's default branch—rather than the untrusted code from the fork—it is treated as trusted [1][2]. As a result, workflows using pull_request_target receive a GITHUB_TOKEN with the permissions defined in the workflow (or repository defaults) and have access to secrets [1][2][3]. Key security considerations include: 1. Permission Adjustment: For all pull request-related events on a fork, any write permissions requested in the workflow are adjusted down to read-only, unless the repository administrator has explicitly enabled the "Send write tokens to workflows from pull requests" setting (which is generally discouraged for public repositories) [9][4][5][6]. 2. Pwn Requests: Using pull_request_target while checking out the head code of a fork PR creates a "pwn request" vulnerability, where untrusted code executes with privileged access [1][10][3]. To mitigate this, actions/checkout v7 and later includes built-in protections that refuse to fetch code from fork pull requests in pull_request_target workflows unless the allow-unsafe-pr-checkout: true flag is explicitly set [10]. 3. Best Practices: It is recommended to use an unprivileged pull_request workflow to test untrusted code and report results, followed by a separate, privileged workflow_run or pull_request_target workflow (that does not check out fork code) to perform sensitive actions [3][8][11]. For further guidance, consult the official documentation on securely using pull_request_target [1][2] and managing GitHub Actions security settings [9].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 2: https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/securely-using-pull_request_target
- 3: https://github.com/github/codeql/blob/main/actions/ql/src/Security/CWE-829/UntrustedCheckoutMedium.md
- 4: Clarify Permissions Calculation for Workflow Jobs in Documentation github/docs#33566
- 5: Clarify
How the permissions are calculated for a workflow jobgithub/docs#32398 - 6: https://docs.github.com/en/enterprise-server@3.2/actions/reference/authentication-in-a-workflow
- 7: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
- 8: https://github.com/github/docs/blob/962a1c8dccb8c0f66548b324e5b921b5e4fbc3d6/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md
- 9: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
- 10: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/
- 11: https://phpunit.expert/articles/hardening-github-actions-workflows.html
🌐 Web query:
GitHub REST API pull_request contents read required token permissions GITHUB_TOKEN fork
💡 Result:
To access pull request contents via the GitHub REST API using the GITHUB_TOKEN in a GitHub Actions workflow, the required permissions depend on whether the pull request originates from a fork and your specific security configuration [1][2][3]. Key Considerations for Forked Pull Requests: 1. Restriction for Public Forks: If a workflow is triggered by a pull request from a public fork, the GITHUB_TOKEN is automatically limited to read-only permissions by GitHub [2][3]. This restriction is enforced regardless of any explicit permissions defined in your workflow file (YAML) or repository settings [3]. 2. Permission Escalation: If your workflow requires write access for actions on pull requests from public forks, you cannot use the GITHUB_TOKEN [3]. Instead, you must use a personal access token (PAT) or a GitHub App installation access token stored as a repository secret [4][5][6]. 3. Event Context: When using the standard pull_request event, these restrictions apply to maintain security [5][7]. If you use the pull_request_target event, the GITHUB_TOKEN may be granted broader (read/write) access even for forks, but this comes with significant security risks as it may allow unreviewed code to execute with elevated permissions [2][7]. Required Permissions Configuration: To read pull request contents or metadata, your workflow should explicitly request the necessary permissions in the YAML file to follow the principle of least privilege [4][6]. For example: permissions: pull-requests: read contents: read If you fail to include these explicitly, they default to none (or read, depending on repository settings), which can cause 403 Forbidden errors when calling API endpoints [3][8][7]. You can verify the required permissions for any specific REST API endpoint by checking the X-Accepted-GitHub-Permissions header in the API response [9].
Citations:
- 1: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
- 2: https://help.github.com/en/enterprise-server@3.5/actions/security-guides/automatic-token-authentication
- 3: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
- 4: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
- 5: https://docs.github.com/en/actions/concepts/security/github_token
- 6: https://docs.github.com/actions/reference/authentication-in-a-workflow
- 7: https://stackoverflow.com/questions/78444367/github-token-permission-in-workflow-changes-to-read-after-setting-it-to-write
- 8: Add missing GitHub permissions to workflows using GitHub API toolsets github/gh-aw#10020
- 9: https://docs.github.com/en/rest/using-the-rest-api/troubleshooting-the-rest-api
🌐 Web query:
GitHub REST Pull Request API default token contents permission required permission contents: read
💡 Result:
To determine the permissions required for GitHub REST API pull request operations, you should consult the X-Accepted-GitHub-Permissions response header provided by the GitHub API when a request fails due to insufficient access [1][2][3]. There is no single default token content permission for all pull request operations, as requirements vary by endpoint and action [1][2][4]. Key points regarding GitHub API permissions for pull requests: 1. Dynamic Permission Discovery: The most reliable way to identify the exact permissions needed (e.g., contents=read, pull_requests=read, etc.) is to inspect the X-Accepted-GitHub-Permissions header in your API response [1][2][3]. This header provides a comma-separated list of required permissions [1]. 2. Permission Granularity: For fine-grained personal access tokens (PATs) and GitHub Apps, permissions are modular [5][6]. While pull_requests is a common permission required for managing pull request metadata, some operations—particularly those involving repository contents or specific branch interactions—may require the contents permission set to read or write [7][1]. 3. Documentation: Official documentation for each specific REST API endpoint (such as the Pulls API) lists the necessary permissions required to call that endpoint [7][8]. Always refer to the endpoint-specific documentation or the troubleshooting guide to ensure your token or app has the correct access level [1]. 4. Access Levels: Permissions generally support read, write, or admin levels [5][6]. Note that write access implicitly includes read access, and admin access implicitly includes write access [5][6]. If you are encountering a "Resource not accessible by integration" or "Resource not accessible by personal access token" error, check the specific documentation for the endpoint you are calling or verify the error header to confirm if you need to elevate your token's permissions to include contents=read or other requirements [1].
Citations:
- 1: https://docs.github.com/en/rest/using-the-rest-api/troubleshooting-the-rest-api
- 2: https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2026-03-10
- 3: https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens
- 4: https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps
- 5: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens?versionId=free-pro-team
- 6: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens?WT.mc_id=25daysofserverless-github-jopapa
- 7: https://docs.github.com/en/rest/pulls/pulls
- 8: https://docs.github.com/en/rest/pulls/pulls?apiVersion=2026-03-10
🌐 Web query:
GitHub GraphQL API GITHUB_TOKEN permissions pull_request query search required permissions contents read
💡 Result:
To query Pull Request information using the GitHub GraphQL API within a GitHub Actions workflow using the GITHUB_TOKEN, you must configure the appropriate permissions in your workflow YAML file [1][2]. Required Permissions For standard read-only queries on pull requests (such as retrieving metadata, comments, or reviewers), you must explicitly grant the pull-requests: read permission [2][3]. If your query also requires accessing the repository's files or commit information, you should additionally grant the contents: read permission [2][3]. Configuration Example You can define these permissions at the workflow or job level: permissions: pull-requests: read contents: read Workflow Configuration 1. Permissions Context: When you specify a permissions block, any permission not explicitly listed is set to none [2]. Always ensure all necessary scopes are included [3]. 2. Default Settings: If no permissions are explicitly defined, workflows default to a restricted set [3]. While this default includes read access to many areas, it is a security best practice to explicitly declare only the permissions your job requires [1][3]. 3. Special Case (Forks): Note that GITHUB_TOKEN permissions are limited when a workflow is triggered by a pull request from a public fork; in these cases, the token is automatically downgraded to read-only access, regardless of your configured permissions [4][2]. Troubleshooting If you receive a 401 Unauthorized or 403 Forbidden error, it typically indicates that the token lacks the specific scope required for the requested data or the endpoint [5][6][7]. You can verify the required scope by checking the GitHub GraphQL API documentation for the specific object or field you are querying [5][8]. If the GITHUB_TOKEN remains insufficient for your needs, GitHub recommends using a GitHub App installation access token or a personal access token (stored as a secret) instead [1][4].
Citations:
- 1: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
- 2: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
- 3: https://adhdecode.com/articles/github-actions/github-actions-workflow-permissions/
- 4: https://docs.github.com/en/actions/concepts/security/github_token
- 5: https://docs.github.com/en/graphql/guides/forming-calls-with-graphql
- 6: https://docs.github.com/en/graphql/guides/introduction-to-graphql
- 7: https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app
- 8: https://docs.github.com/en/graphql/reference/pulls
🌐 Web query:
GitHub Actions automatic token authentication fork pull_request permissions contents read only README GitHub
💡 Result:
When a GitHub Actions workflow is triggered by a pull request from a forked repository, GitHub automatically restricts the permissions of the GITHUB_TOKEN to enhance security [1][2][3]. Key points regarding this behavior: 1. Read-Only Restriction: By default, if a workflow is triggered by a pull request from a fork, any write permissions requested in the workflow file are downgraded to read-only [4][5][6]. This applies to all pull request-related events (such as pull_request, pull_request_review, etc.) with one critical exception [4][5]. 2. The Exception (pull_request_target): The pull_request_target event is the primary exception to this rule [4][5]. Because this event runs the workflow using the code from the base repository's default branch rather than the untrusted fork's merge commit, it is considered safe to grant it full read/write permissions and access to secrets [2][3]. 3. Administrative Override: Repository administrators can change this default behavior in the repository's Actions settings [7][1]. Specifically, there is an option to "Send write tokens to workflows from pull requests." If this setting is enabled, pull requests from forks can use a GITHUB_TOKEN with write permissions [7][1][6]. 4. Security Best Practices: Because the GITHUB_TOKEN is essentially a GitHub App installation access token with permissions limited to the repository, you should always explicitly define the minimum required permissions using the permissions key in your workflow file [1][8][9]. If a workflow requires elevated privileges that the GITHUB_TOKEN cannot provide (even with administrative overrides), you should use a dedicated GitHub App or a personal access token stored as a secret [8][9].
Citations:
- 1: https://docs.github.com/en/enterprise-server@3.13/actions/security-guides/automatic-token-authentication
- 2: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 3: https://stackoverflow.com/questions/74957218/what-is-the-difference-between-pull-request-and-pull-request-target-event-in-git
- 4: Clarify Permissions Calculation for Workflow Jobs in Documentation github/docs#33566
- 5: Clarify
How the permissions are calculated for a workflow jobgithub/docs#32398 - 6: https://docs.github.com/en/enterprise-server@3.2/actions/reference/authentication-in-a-workflow
- 7: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
- 8: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
- 9: https://docs.github.com/en/actions/concepts/security/github_token
🌐 Web query:
GitHub GraphQL API fetch pull request files changed by file changed contents required permissions
💡 Result:
To fetch the files changed in a pull request using the GitHub GraphQL API, you use the files field on a PullRequest object [1][2]. 1. Fetching File Changes The PullRequest object contains a files field, which returns a PullRequestChangedFileConnection [1][2]. This connection allows you to paginate through the files modified in the pull request. Key fields available for each PullRequestChangedFile node include: - path: The path of the file [1][2]. - additions: The number of additions [1][2]. - deletions: The number of deletions [1][2]. - changeType: The type of change (e.g., added, modified, deleted) [1][2]. - viewerViewedState: The viewing state of the file for the current user [1][2]. Note that the GraphQL API for files is primarily intended for metadata; if you require the actual diff content or patch details, the GitHub REST API (GET /repos/{owner}/{repo}/pulls/{pull_number}/files) remains the standard approach, as it explicitly provides the patch field in the response [3][4][5]. 2. Required Permissions When using a GitHub App or fine-grained personal access token to access this data, you must ensure the following permissions are configured: - Read-only access to "Pull requests" is required [6]. - If accessing private repositories, your token or app must have sufficient repository-level read permissions (e.g., "Metadata" and "Contents" access may also be required depending on the scope of your query) [6]. - If your request fails with a 401 or similar error, it confirms that the credentials provided do not have the necessary scope to access the specific repository or pull request [6]. When configuring these permissions, always adhere to the principle of least privilege by granting only the minimum access level required for your application to function [6].
Citations:
- 1: https://docs.github.com/en/enterprise-cloud@latest/graphql/reference/pulls
- 2: https://docs.github.com/en/graphql/reference/pulls
- 3: https://docs.github.com/en/enterprise-cloud@latest/rest/pulls/pulls
- 4: https://docs.github.com/en/enterprise-server@3.17/rest/pulls/pulls
- 5: https://docs.github.com/en/rest/pulls/pulls?apiVersion=2026-03-10
- 6: https://docs.github.com/en/enterprise-server@3.20/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app
🌐 Web query:
GitHub GraphQL pulls fields files changed first fields pull request files permission contents: read
💡 Result:
To access file information for a pull request using the GitHub GraphQL API, you must use the files connection field within the PullRequest object [1][2]. Because this field is a connection, it requires pagination [3]. Key details include: Pagination and Fields - The files field returns a PullRequestChangedFileConnection [1][2]. - When querying files, you must specify a pagination argument, such as first: n (up to a maximum of 100 nodes per request) [3][4]. - To retrieve more than the initial batch, use the pageInfo object (which provides hasNextPage and endCursor) and the after argument to request subsequent pages [1][3][4]. - Available fields on the PullRequestChangedFile object include path, additions, deletions, changeType, and viewerViewedState [1][2]. - The PullRequest object also provides a changedFiles field, which returns an integer representing the total count of files changed [1][2]. Permissions - Accessing repository data via the GraphQL API requires appropriate permissions. For GitHub Apps and personal access tokens, the "Contents" repository permission is typically required to read repository content [5]. - If you are using a GitHub Action, ensure your workflow is configured with the necessary permissions (e.g., contents: read) in its permissions block [5][6]. - If a request is made with insufficient permissions, the API will return a 401 or 403 error [5][6]. Example Query Structure { repository(owner: "OWNER", name: "REPO") { pullRequest(number: PR_NUMBER) { files(first: 100, after: "CURSOR") { nodes { path additions deletions changeType } pageInfo { hasNextPage endCursor } } } } }
Citations:
- 1: https://docs.github.com/en/graphql/reference/pulls
- 2: https://docs.github.com/en/enterprise-cloud@latest/graphql/reference/pulls
- 3: Remove restrictions of
gh pr view --json filescli/cli#5368 - 4: fix(github): paginate the GraphQL PR-detail fallback's files/reviews past 100 nodes JSONbored/loopover#7453
- 5: https://docs.github.com/en/enterprise-server@3.21/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app
- 6: Add missing GitHub permissions to workflows using GitHub API toolsets github/gh-aw#10020
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== e2e tests suite =="
cat -n e2e/tests_suite_test.go | sed -n '1,130p'
echo "== mergequeue relevant implementation =="
cat -n pkg/mergequeue/main.go | sed -n '1,230p'
echo "== run tests direct references =="
rg -n 'FetchPRTimelineItems|OpenPRsAt|MergedPRsBetween|ChatopsMergedPRsBetween|GetSupportedBranches|run tests|go test|GITHUB_TOKEN_PATH|GITHUB_TOKEN' pkg e2e --glob '*.go' --glob '*.yaml' --glob '*.yml'Repository: kubevirt/ci-health
Length of output: 16725
Add pull-requests: read to the GitHub token permissions.
This workflow passes GITHUB_TOKEN into go test ./..., and the test suite exercises GitHub GraphQL queries against public PR metadata via shurcooL/githubv4. When permissions is set manually, only the listed permissions are granted; contents: read alone may not authorize pull request metadata reads, causing fork PR runs to fail with authorization errors. Add pull-requests: read as the minimum scope required for these tests.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci-health-tests.yaml around lines 12 - 13, Add the
pull-requests: read permission alongside contents: read in the workflow’s
top-level permissions block so GITHUB_TOKEN can access pull request metadata
during the Go test suite, while preserving the existing minimal permissions.
| |----------|---------|---------| | ||
| | `badges-update.yaml` | Scheduled every 3 hours | Runs `stats` for last 7 days, commits updated badges and `results.json` | | ||
| | `ci-failures.yml` | Push to `main` modifying `results.json` | Runs `ci-failures generate report`, commits updated markdown summary | | ||
| | `ci-health-tests.yml` | Pull request that modifies Go code | Runs `go test`, validates changes | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Correct the workflow filename and trigger description.
The file is ci-health-tests.yaml, not ci-health-tests.yml; additionally, the workflow also triggers on .github/**, not only Go-code changes.
-| `ci-health-tests.yml` | Pull request that modifies Go code | Runs `go test`, validates changes |
+| `ci-health-tests.yaml` | Pull request modifying `cmd/**`, `e2e/**`, `pkg/**`, `go.*`, or `.github/**` | Runs `go test`, validates changes |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | `ci-health-tests.yml` | Pull request that modifies Go code | Runs `go test`, validates changes | | |
| | `ci-health-tests.yaml` | Pull request modifying `cmd/**`, `e2e/**`, `pkg/**`, `go.*`, or `.github/**` | Runs `go test`, validates changes | |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` at line 143, Update the workflow table entry for
ci-health-tests.yaml: correct the filename extension from .yml to .yaml and
revise the trigger description to include changes under .github/** in addition
to Go-code modifications.
dhiller
left a comment
dhiller
left a comment
There was a problem hiding this comment.
Two questions: we want to run on forks using the original GitHub Action secrets, so
- how do we enable that?
- and how do we make sure they are not leaked?
| jobs: | ||
| test: | ||
| runs-on: ubuntu-latest | ||
| container: docker.io/golang:1.26-alpine |
There was a problem hiding this comment.
being curious: how does GitHub Actions handle the rate limiting by docker? Do we need to mirror images in the long run if we get instability here?
Hi @dhiller Initially, I wanted to use the event pull_request_target so that the tests would run in the context of the upstream repo (with access to the secrets) instead of the fork. To minimize the risk of leaks, the triggering of the action would have been restricted to trusted collaborators, similar to Prow. However, I realised that this wasn’t actually necessary and reverted to the standard pull_request event. As all calls to the GitHub API in the tests are made to public resources, the temporary token provided by the GitHub action itself can be used: The token |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhiller The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kubevirt-prow
Bot
added
the
approved
2 participants
What this PR does / why we need it:
Bring back the GitHub action which was used to validate go code changes.
It seems using the token from the github action itself is sufficient to query the required data.
Therefore, there is no need to switch to the
pull_request_targetevent to expose the token from the repository variables.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #130
Special notes for your reviewer:
/cc @dhiller
Summary by CodeRabbit
New Features
Documentation