Files

1 line
33 KiB
JSON

{"repo": "bigbanana-7788/nofx", "files": {"mcp/deepseek_client.go": {"f4b8e573b29ebf9d05926911c5a86498c20dd106": {"t": 1785746057.5643718, "n": 1305, "h": "004f6f9332ff8939", "c": "package mcp\n\nimport (\n\t\"log\"\n\t\"net/http\"\n)\n\nconst (\n\tProviderDeepSeek = \"deepseek\"\n\tDefaultDeepSeekBaseURL = \"https://api.deepseek.com/v1\"\n\tDefaultDeepSeekModel = \"deepseek-chat\"\n)\n\ntype DeepSeekClient struct {\n\t*Client\n}\n\nfunc NewDeepSeekClient() AIClient {\n\tclient := New().(*Client)\n\tclient.Provider = ProviderDeepSeek\n\tclient.Model = DefaultDeepSeekModel\n\tclient.BaseURL = DefaultDeepSeekBaseURL\n\treturn &DeepSeekClient{\n\t\tClient: client,\n\t}\n}\n\nfunc (dsClient *DeepSeekClient) SetAPIKey(apiKey string, customURL string, customModel string) {\n\tif dsClient.Client == nil {\n\t\tdsClient.Client = New().(*Client)\n\t}\n\tdsClient.Client.APIKey = apiKey\n\n\tif len(apiKey) > 8 {\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek API Key: %s...%s\", apiKey[:4], apiKey[len(apiKey)-4:])\n\t}\n\tif customURL != \"\" {\n\t\tdsClient.Client.BaseURL = customURL\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek 使用自定义 BaseURL: %s\", customURL)\n\t} else {\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek 使用默认 BaseURL: %s\", dsClient.Client.BaseURL)\n\t}\n\tif customModel != \"\" {\n\t\tdsClient.Client.Model = customModel\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek 使用自定义 Model: %s\", customModel)\n\t} else {\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek 使用默认 Model: %s\", dsClient.Client.Model)\n\t}\n}\n\nfunc (dsClient *DeepSeekClient) setAuthHeader(reqHeaders http.Header) {\n\tdsClient.Client.setAuthHeader(reqHeaders)\n}\n"}, "5753394c38e3c014453e9fa3a5682bfb633b2cf6": {"t": 1785759293.5922601, "n": 1305, "h": "004f6f9332ff8939", "c": "package mcp\n\nimport (\n\t\"log\"\n\t\"net/http\"\n)\n\nconst (\n\tProviderDeepSeek = \"deepseek\"\n\tDefaultDeepSeekBaseURL = \"https://api.deepseek.com/v1\"\n\tDefaultDeepSeekModel = \"deepseek-chat\"\n)\n\ntype DeepSeekClient struct {\n\t*Client\n}\n\nfunc NewDeepSeekClient() AIClient {\n\tclient := New().(*Client)\n\tclient.Provider = ProviderDeepSeek\n\tclient.Model = DefaultDeepSeekModel\n\tclient.BaseURL = DefaultDeepSeekBaseURL\n\treturn &DeepSeekClient{\n\t\tClient: client,\n\t}\n}\n\nfunc (dsClient *DeepSeekClient) SetAPIKey(apiKey string, customURL string, customModel string) {\n\tif dsClient.Client == nil {\n\t\tdsClient.Client = New().(*Client)\n\t}\n\tdsClient.Client.APIKey = apiKey\n\n\tif len(apiKey) > 8 {\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek API Key: %s...%s\", apiKey[:4], apiKey[len(apiKey)-4:])\n\t}\n\tif customURL != \"\" {\n\t\tdsClient.Client.BaseURL = customURL\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek 使用自定义 BaseURL: %s\", customURL)\n\t} else {\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek 使用默认 BaseURL: %s\", dsClient.Client.BaseURL)\n\t}\n\tif customModel != \"\" {\n\t\tdsClient.Client.Model = customModel\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek 使用自定义 Model: %s\", customModel)\n\t} else {\n\t\tlog.Printf(\"🔧 [MCP] DeepSeek 使用默认 Model: %s\", dsClient.Client.Model)\n\t}\n}\n\nfunc (dsClient *DeepSeekClient) setAuthHeader(reqHeaders http.Header) {\n\tdsClient.Client.setAuthHeader(reqHeaders)\n}\n"}}, ".github/workflows/README.md": {"f4b8e573b29ebf9d05926911c5a86498c20dd106": {"t": 1785747015.222336, "n": 7637, "h": "a70debc0c1de7ff3", "c": "# GitHub Actions Workflows\n\nThis directory contains the GitHub Actions workflows for the NOFX project.\n\n## 📚 Documentation Index\n\n- **[README.md](./README.md)** - This file, overview of all workflows\n- **[PERMISSIONS.md](./PERMISSIONS.md)** - Detailed permission analysis and security model\n- **[TRIGGERS.md](./TRIGGERS.md)** - Comparison of event triggers (pull_request vs pull_request_target vs workflow_run)\n- **[FORK_PR_FLOW.md](./FORK_PR_FLOW.md)** - Complete analysis of what happens when a fork PR is submitted\n- **[FLOW_DIAGRAM.md](./FLOW_DIAGRAM.md)** - Visual flow diagrams and quick reference\n- **[SECRETS_SCANNING.md](./SECRETS_SCANNING.md)** - Secrets scanning solutions and TruffleHog setup\n\n## 🚀 Quick Start\n\n**Want to understand how fork PRs work?** → Read [FLOW_DIAGRAM.md](./FLOW_DIAGRAM.md)\n\n**Need security details?** → Read [PERMISSIONS.md](./PERMISSIONS.md)\n\n**Confused about triggers?** → Read [TRIGGERS.md](./TRIGGERS.md)\n\n## Automation Workflows\n\n### `translate-issues.yml` - Auto Translate Issues\n\nAutomatically translates GitHub issues between Chinese and English using DeepSeek API.\n\n**Features:**\n- ✅ Detects issue language (Chinese/English)\n- ✅ Translates to the opposite language\n- ✅ Adds translation as a comment\n- ✅ Preserves markdown formatting, code blocks, and links\n- ✅ Cost-effective (uses DeepSeek API)\n\n**How it works:**\n1. Triggered when an issue is opened or edited\n2. Detects if the issue is primarily in Chinese or English\n3. Translates to the opposite language using DeepSeek API\n4. Adds the translation as a comment\n\n**Setup:**\n\nThis workflow requires a DeepSeek API key to be configured as a GitHub secret:\n\n1. Get your DeepSeek API key from https://platform.deepseek.com/\n2. Go to repository Settings → Secrets and variables → Actions\n3. Click \"New repository secret\"\n4. Name: `DEEPSEEK_API_KEY`\n5. Value: Your DeepSeek API key\n6. Click \"Add secret\"\n\n**Cost:**\n- DeepSeek API is very affordable (~$0.001 per issue translation)\n- Much cheaper than GPT-4 or Claude\n\n**Skipping translation:**\nIf `DEEPSEEK_API_KEY` is not set, the workflow will skip translation gracefully.\n\n### `test.yml` - Test Workflow\n\nRuns backend and frontend tests on push/PR.\n\n**Features:**\n- ✅ Backend tests (Go)\n- ✅ Frontend tests (Vitest)\n- ✅ Non-blocking (won't prevent PR merges)\n\nSee [PR #229](https://github.com/tinkle-community/nofx/pull/229) for details.\n\n## PR Check Workflows\n\nWe use a **two-workflow pattern** to safely handle PR checks from both internal and fork PRs:\n\n### 1. `pr-checks-run.yml` - Execute Checks\n\n**Trigger:** On pull request (opened, synchronize, reopened)\n\n**Permissions:** Read-only\n\n**Purpose:** Executes all PR checks with read-only permissions, making it safe for fork PRs.\n\n**What it does:**\n- ✅ Checks PR title format (Conventional Commits)\n- ✅ Calculates PR size\n- ✅ Runs backend checks (Go formatting, vet, tests)\n- ✅ Runs frontend checks (linting, type checking, build)\n- ✅ Saves all results as artifacts\n\n**Security:** Safe for fork PRs because it only has read permissions and cannot access secrets or modify the repository.\n\n### 2. `pr-checks-comment.yml` - Post Results\n\n**Trigger:** When `pr-checks-run.yml` completes (workflow_run)\n\n**Permissions:** Write (pull-requests, issues)\n\n**Purpose:** Posts check results as PR comments, running in the main repository context.\n\n**What it does:**\n- ✅ Downloads artifacts from `pr-checks-run.yml`\n- ✅ Reads check results\n- ✅ Posts a comprehensive comment to the PR\n\n**Security:** Safe because:\n- Runs in the main repository context (not fork context)\n- Has write permissions but doesn't execute untrusted code\n- Only reads pre-generated results from artifacts\n\n### 3. `pr-checks.yml` - Strict Checks\n\n**Trigger:** On pull request\n\n**Permissions:** Read + conditional write\n\n**Purpose:** Runs mandatory checks that must pass before PR can be merged.\n\n**What it does:**\n- ✅ Validates PR title (blocks merge if invalid)\n- ✅ Auto-labels PR based on size and files changed (non-fork only)\n- ✅ Runs backend tests (Go)\n- ✅ Runs frontend tests (React/TypeScript)\n- ✅ Security scanning (Trivy, Gitleaks)\n\n**Security:**\n- Fork PRs: Only runs read-only operations (tests, security scans)\n- Non-fork PRs: Can add labels and comments\n- Uses `continue-on-error` for operations that may fail on forks\n\n## Why Two Workflows for PR Checks?\n\n### The Problem\n\nWhen a PR comes from a forked repository:\n- GitHub restricts `GITHUB_TOKEN` permissions for security\n- Fork PRs cannot write comments, add labels, or access secrets\n- This prevents malicious contributors from:\n - Stealing repository secrets\n - Modifying workflow files to execute malicious code\n - Spamming issues/PRs with automated comments\n\n### The Solution\n\n**Two-Workflow Pattern:**\n\n```\nFork PR Submitted\n ↓\n[pr-checks-run.yml]\n - Runs with read-only permissions\n - Executes all checks safely\n - Saves results to artifacts\n ↓\n[pr-checks-comment.yml]\n - Triggered by workflow_run\n - Runs in main repo context (has write permissions)\n - Downloads artifacts\n - Posts comment with results\n```\n\nThis approach:\n- ✅ Allows fork PRs to run checks\n- ✅ Safely posts results as comments\n- ✅ Prevents security vulnerabilities\n- ✅ Follows GitHub's best practices\n\n### Can workflow_run Comment on Fork PRs?\n\n**Yes! ✅ The permissions are sufficient.**\n\n**Key Understanding:**\n- `workflow_run` executes in the **base repository** context\n- Fork PRs exist in the **base repository** (not in the fork)\n- The base repository's `GITHUB_TOKEN` has write permissions\n- Therefore, `workflow_run` can comment on fork PRs\n\n**Security:**\n- Fork PR code runs in isolated environment (read-only)\n- Comment workflow doesn't execute fork code\n- Only reads pre-generated artifact data\n\n**For detailed permission analysis, see:** [PERMISSIONS.md](./PERMISSIONS.md)\n\n## Workflow Comparison\n\n| Workflow | Fork PRs | Write Access | Blocks Merge | Purpose |\n|----------|----------|--------------|--------------|---------|\n| `pr-checks-run.yml` | ✅ Yes | ❌ No | ❌ No | Advisory checks |\n| `pr-checks-comment.yml` | ✅ Yes | ✅ Yes* | ❌ No | Post results |\n| `pr-checks.yml` | ✅ Yes | ⚠️ Partial | ✅ Yes | Mandatory checks |\n\n\\* Write access only in main repo context, not available to fork PR code\n\n## File History\n\n- `pr-checks-advisory.yml.old` - Old advisory workflow that failed on fork PRs (deprecated)\n- Now replaced by the two-workflow pattern (`pr-checks-run.yml` + `pr-checks-comment.yml`)\n\n## Testing the Workflows\n\n### Test with a Fork PR\n\n1. Fork the repository\n2. Make changes in your fork\n3. Create a PR to the main repository\n4. Observe:\n - `pr-checks-run.yml` runs successfully with read-only access\n - `pr-checks-comment.yml` posts results as a comment\n - `pr-checks.yml` runs tests but skips labeling\n\n### Test with a Branch PR\n\n1. Create a branch in the main repository\n2. Make changes\n3. Create a PR\n4. Observe:\n - All workflows run with full permissions\n - Labels are added automatically\n - Comments are posted\n\n## References\n\n- [GitHub Actions: Keeping your GitHub Actions and workflows secure Part 1](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)\n- [Safely posting comments from untrusted workflows](https://securitylab.github.com/research/github-actions-building-blocks/)\n- [GitHub Actions: workflow_run trigger](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)\n\n## Contributing\n\nWhen adding new workflows:\n1. Test locally first if possible\n2. Document the workflow in this README\n3. Add any required secrets to the setup instructions\n4. Make workflows non-blocking unless critical\n"}, "8d0ebefe55391e7317adeb643242ebd619c6a853": {"t": 1785759297.1387665, "n": 7637, "h": "a70debc0c1de7ff3", "c": "# GitHub Actions Workflows\n\nThis directory contains the GitHub Actions workflows for the NOFX project.\n\n## 📚 Documentation Index\n\n- **[README.md](./README.md)** - This file, overview of all workflows\n- **[PERMISSIONS.md](./PERMISSIONS.md)** - Detailed permission analysis and security model\n- **[TRIGGERS.md](./TRIGGERS.md)** - Comparison of event triggers (pull_request vs pull_request_target vs workflow_run)\n- **[FORK_PR_FLOW.md](./FORK_PR_FLOW.md)** - Complete analysis of what happens when a fork PR is submitted\n- **[FLOW_DIAGRAM.md](./FLOW_DIAGRAM.md)** - Visual flow diagrams and quick reference\n- **[SECRETS_SCANNING.md](./SECRETS_SCANNING.md)** - Secrets scanning solutions and TruffleHog setup\n\n## 🚀 Quick Start\n\n**Want to understand how fork PRs work?** → Read [FLOW_DIAGRAM.md](./FLOW_DIAGRAM.md)\n\n**Need security details?** → Read [PERMISSIONS.md](./PERMISSIONS.md)\n\n**Confused about triggers?** → Read [TRIGGERS.md](./TRIGGERS.md)\n\n## Automation Workflows\n\n### `translate-issues.yml` - Auto Translate Issues\n\nAutomatically translates GitHub issues between Chinese and English using DeepSeek API.\n\n**Features:**\n- ✅ Detects issue language (Chinese/English)\n- ✅ Translates to the opposite language\n- ✅ Adds translation as a comment\n- ✅ Preserves markdown formatting, code blocks, and links\n- ✅ Cost-effective (uses DeepSeek API)\n\n**How it works:**\n1. Triggered when an issue is opened or edited\n2. Detects if the issue is primarily in Chinese or English\n3. Translates to the opposite language using DeepSeek API\n4. Adds the translation as a comment\n\n**Setup:**\n\nThis workflow requires a DeepSeek API key to be configured as a GitHub secret:\n\n1. Get your DeepSeek API key from https://platform.deepseek.com/\n2. Go to repository Settings → Secrets and variables → Actions\n3. Click \"New repository secret\"\n4. Name: `DEEPSEEK_API_KEY`\n5. Value: Your DeepSeek API key\n6. Click \"Add secret\"\n\n**Cost:**\n- DeepSeek API is very affordable (~$0.001 per issue translation)\n- Much cheaper than GPT-4 or Claude\n\n**Skipping translation:**\nIf `DEEPSEEK_API_KEY` is not set, the workflow will skip translation gracefully.\n\n### `test.yml` - Test Workflow\n\nRuns backend and frontend tests on push/PR.\n\n**Features:**\n- ✅ Backend tests (Go)\n- ✅ Frontend tests (Vitest)\n- ✅ Non-blocking (won't prevent PR merges)\n\nSee [PR #229](https://github.com/tinkle-community/nofx/pull/229) for details.\n\n## PR Check Workflows\n\nWe use a **two-workflow pattern** to safely handle PR checks from both internal and fork PRs:\n\n### 1. `pr-checks-run.yml` - Execute Checks\n\n**Trigger:** On pull request (opened, synchronize, reopened)\n\n**Permissions:** Read-only\n\n**Purpose:** Executes all PR checks with read-only permissions, making it safe for fork PRs.\n\n**What it does:**\n- ✅ Checks PR title format (Conventional Commits)\n- ✅ Calculates PR size\n- ✅ Runs backend checks (Go formatting, vet, tests)\n- ✅ Runs frontend checks (linting, type checking, build)\n- ✅ Saves all results as artifacts\n\n**Security:** Safe for fork PRs because it only has read permissions and cannot access secrets or modify the repository.\n\n### 2. `pr-checks-comment.yml` - Post Results\n\n**Trigger:** When `pr-checks-run.yml` completes (workflow_run)\n\n**Permissions:** Write (pull-requests, issues)\n\n**Purpose:** Posts check results as PR comments, running in the main repository context.\n\n**What it does:**\n- ✅ Downloads artifacts from `pr-checks-run.yml`\n- ✅ Reads check results\n- ✅ Posts a comprehensive comment to the PR\n\n**Security:** Safe because:\n- Runs in the main repository context (not fork context)\n- Has write permissions but doesn't execute untrusted code\n- Only reads pre-generated results from artifacts\n\n### 3. `pr-checks.yml` - Strict Checks\n\n**Trigger:** On pull request\n\n**Permissions:** Read + conditional write\n\n**Purpose:** Runs mandatory checks that must pass before PR can be merged.\n\n**What it does:**\n- ✅ Validates PR title (blocks merge if invalid)\n- ✅ Auto-labels PR based on size and files changed (non-fork only)\n- ✅ Runs backend tests (Go)\n- ✅ Runs frontend tests (React/TypeScript)\n- ✅ Security scanning (Trivy, Gitleaks)\n\n**Security:**\n- Fork PRs: Only runs read-only operations (tests, security scans)\n- Non-fork PRs: Can add labels and comments\n- Uses `continue-on-error` for operations that may fail on forks\n\n## Why Two Workflows for PR Checks?\n\n### The Problem\n\nWhen a PR comes from a forked repository:\n- GitHub restricts `GITHUB_TOKEN` permissions for security\n- Fork PRs cannot write comments, add labels, or access secrets\n- This prevents malicious contributors from:\n - Stealing repository secrets\n - Modifying workflow files to execute malicious code\n - Spamming issues/PRs with automated comments\n\n### The Solution\n\n**Two-Workflow Pattern:**\n\n```\nFork PR Submitted\n ↓\n[pr-checks-run.yml]\n - Runs with read-only permissions\n - Executes all checks safely\n - Saves results to artifacts\n ↓\n[pr-checks-comment.yml]\n - Triggered by workflow_run\n - Runs in main repo context (has write permissions)\n - Downloads artifacts\n - Posts comment with results\n```\n\nThis approach:\n- ✅ Allows fork PRs to run checks\n- ✅ Safely posts results as comments\n- ✅ Prevents security vulnerabilities\n- ✅ Follows GitHub's best practices\n\n### Can workflow_run Comment on Fork PRs?\n\n**Yes! ✅ The permissions are sufficient.**\n\n**Key Understanding:**\n- `workflow_run` executes in the **base repository** context\n- Fork PRs exist in the **base repository** (not in the fork)\n- The base repository's `GITHUB_TOKEN` has write permissions\n- Therefore, `workflow_run` can comment on fork PRs\n\n**Security:**\n- Fork PR code runs in isolated environment (read-only)\n- Comment workflow doesn't execute fork code\n- Only reads pre-generated artifact data\n\n**For detailed permission analysis, see:** [PERMISSIONS.md](./PERMISSIONS.md)\n\n## Workflow Comparison\n\n| Workflow | Fork PRs | Write Access | Blocks Merge | Purpose |\n|----------|----------|--------------|--------------|---------|\n| `pr-checks-run.yml` | ✅ Yes | ❌ No | ❌ No | Advisory checks |\n| `pr-checks-comment.yml` | ✅ Yes | ✅ Yes* | ❌ No | Post results |\n| `pr-checks.yml` | ✅ Yes | ⚠️ Partial | ✅ Yes | Mandatory checks |\n\n\\* Write access only in main repo context, not available to fork PR code\n\n## File History\n\n- `pr-checks-advisory.yml.old` - Old advisory workflow that failed on fork PRs (deprecated)\n- Now replaced by the two-workflow pattern (`pr-checks-run.yml` + `pr-checks-comment.yml`)\n\n## Testing the Workflows\n\n### Test with a Fork PR\n\n1. Fork the repository\n2. Make changes in your fork\n3. Create a PR to the main repository\n4. Observe:\n - `pr-checks-run.yml` runs successfully with read-only access\n - `pr-checks-comment.yml` posts results as a comment\n - `pr-checks.yml` runs tests but skips labeling\n\n### Test with a Branch PR\n\n1. Create a branch in the main repository\n2. Make changes\n3. Create a PR\n4. Observe:\n - All workflows run with full permissions\n - Labels are added automatically\n - Comments are posted\n\n## References\n\n- [GitHub Actions: Keeping your GitHub Actions and workflows secure Part 1](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)\n- [Safely posting comments from untrusted workflows](https://securitylab.github.com/research/github-actions-building-blocks/)\n- [GitHub Actions: workflow_run trigger](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)\n\n## Contributing\n\nWhen adding new workflows:\n1. Test locally first if possible\n2. Document the workflow in this README\n3. Add any required secrets to the setup instructions\n4. Make workflows non-blocking unless critical\n"}, "0500cf74863397cfaa9de355acac49ce1598babf": {"t": 1785759298.7206922, "n": 5979, "h": "1b0a1f1269083d29", "c": "# GitHub Actions Workflows\n\nThis directory contains the GitHub Actions workflows for the NOFX project.\n\n## 📚 Documentation Index\n\n- **[README.md](./README.md)** - This file, overview of all workflows\n- **[PERMISSIONS.md](./PERMISSIONS.md)** - Detailed permission analysis and security model\n- **[TRIGGERS.md](./TRIGGERS.md)** - Comparison of event triggers (pull_request vs pull_request_target vs workflow_run)\n- **[FORK_PR_FLOW.md](./FORK_PR_FLOW.md)** - Complete analysis of what happens when a fork PR is submitted\n- **[FLOW_DIAGRAM.md](./FLOW_DIAGRAM.md)** - Visual flow diagrams and quick reference\n- **[SECRETS_SCANNING.md](./SECRETS_SCANNING.md)** - Secrets scanning solutions and TruffleHog setup\n\n## 🚀 Quick Start\n\n**Want to understand how fork PRs work?** → Read [FLOW_DIAGRAM.md](./FLOW_DIAGRAM.md)\n\n**Need security details?** → Read [PERMISSIONS.md](./PERMISSIONS.md)\n\n**Confused about triggers?** → Read [TRIGGERS.md](./TRIGGERS.md)\n\n## PR Check Workflows\n\nWe use a **two-workflow pattern** to safely handle PR checks from both internal and fork PRs:\n\n### 1. `pr-checks-run.yml` - Execute Checks\n\n**Trigger:** On pull request (opened, synchronize, reopened)\n\n**Permissions:** Read-only\n\n**Purpose:** Executes all PR checks with read-only permissions, making it safe for fork PRs.\n\n**What it does:**\n- ✅ Checks PR title format (Conventional Commits)\n- ✅ Calculates PR size\n- ✅ Runs backend checks (Go formatting, vet, tests)\n- ✅ Runs frontend checks (linting, type checking, build)\n- ✅ Saves all results as artifacts\n\n**Security:** Safe for fork PRs because it only has read permissions and cannot access secrets or modify the repository.\n\n### 2. `pr-checks-comment.yml` - Post Results\n\n**Trigger:** When `pr-checks-run.yml` completes (workflow_run)\n\n**Permissions:** Write (pull-requests, issues)\n\n**Purpose:** Posts check results as PR comments, running in the main repository context.\n\n**What it does:**\n- ✅ Downloads artifacts from `pr-checks-run.yml`\n- ✅ Reads check results\n- ✅ Posts a comprehensive comment to the PR\n\n**Security:** Safe because:\n- Runs in the main repository context (not fork context)\n- Has write permissions but doesn't execute untrusted code\n- Only reads pre-generated results from artifacts\n\n### 3. `pr-checks.yml` - Strict Checks\n\n**Trigger:** On pull request\n\n**Permissions:** Read + conditional write\n\n**Purpose:** Runs mandatory checks that must pass before PR can be merged.\n\n**What it does:**\n- ✅ Validates PR title (blocks merge if invalid)\n- ✅ Auto-labels PR based on size and files changed (non-fork only)\n- ✅ Runs backend tests (Go)\n- ✅ Runs frontend tests (React/TypeScript)\n- ✅ Security scanning (Trivy, Gitleaks)\n\n**Security:**\n- Fork PRs: Only runs read-only operations (tests, security scans)\n- Non-fork PRs: Can add labels and comments\n- Uses `continue-on-error` for operations that may fail on forks\n\n## Why Two Workflows for PR Checks?\n\n### The Problem\n\nWhen a PR comes from a forked repository:\n- GitHub restricts `GITHUB_TOKEN` permissions for security\n- Fork PRs cannot write comments, add labels, or access secrets\n- This prevents malicious contributors from:\n - Stealing repository secrets\n - Modifying workflow files to execute malicious code\n - Spamming issues/PRs with automated comments\n\n### The Solution\n\n**Two-Workflow Pattern:**\n\n```\nFork PR Submitted\n ↓\n[pr-checks-run.yml]\n - Runs with read-only permissions\n - Executes all checks safely\n - Saves results to artifacts\n ↓\n[pr-checks-comment.yml]\n - Triggered by workflow_run\n - Runs in main repo context (has write permissions)\n - Downloads artifacts\n - Posts comment with results\n```\n\nThis approach:\n- ✅ Allows fork PRs to run checks\n- ✅ Safely posts results as comments\n- ✅ Prevents security vulnerabilities\n- ✅ Follows GitHub's best practices\n\n### Can workflow_run Comment on Fork PRs?\n\n**Yes! ✅ The permissions are sufficient.**\n\n**Key Understanding:**\n- `workflow_run` executes in the **base repository** context\n- Fork PRs exist in the **base repository** (not in the fork)\n- The base repository's `GITHUB_TOKEN` has write permissions\n- Therefore, `workflow_run` can comment on fork PRs\n\n**Security:**\n- Fork PR code runs in isolated environment (read-only)\n- Comment workflow doesn't execute fork code\n- Only reads pre-generated artifact data\n\n**For detailed permission analysis, see:** [PERMISSIONS.md](./PERMISSIONS.md)\n\n## Workflow Comparison\n\n| Workflow | Fork PRs | Write Access | Blocks Merge | Purpose |\n|----------|----------|--------------|--------------|---------|\n| `pr-checks-run.yml` | ✅ Yes | ❌ No | ❌ No | Advisory checks |\n| `pr-checks-comment.yml` | ✅ Yes | ✅ Yes* | ❌ No | Post results |\n| `pr-checks.yml` | ✅ Yes | ⚠️ Partial | ✅ Yes | Mandatory checks |\n\n\\* Write access only in main repo context, not available to fork PR code\n\n## File History\n\n- `pr-checks-advisory.yml.old` - Old advisory workflow that failed on fork PRs (deprecated)\n- Now replaced by the two-workflow pattern (`pr-checks-run.yml` + `pr-checks-comment.yml`)\n\n## Testing the Workflows\n\n### Test with a Fork PR\n\n1. Fork the repository\n2. Make changes in your fork\n3. Create a PR to the main repository\n4. Observe:\n - `pr-checks-run.yml` runs successfully with read-only access\n - `pr-checks-comment.yml` posts results as a comment\n - `pr-checks.yml` runs tests but skips labeling\n\n### Test with a Branch PR\n\n1. Create a branch in the main repository\n2. Make changes\n3. Create a PR\n4. Observe:\n - All workflows run with full permissions\n - Labels are added automatically\n - Comments are posted\n\n## References\n\n- [GitHub Actions: Keeping your GitHub Actions and workflows secure Part 1](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)\n- [Safely posting comments from untrusted workflows](https://securitylab.github.com/research/github-actions-building-blocks/)\n- [GitHub Actions: workflow_run trigger](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)\n"}, "7cbef0fd6516cc29d0a4eb0ea4a64d99e9c055f9": {"t": 1785759300.6761343, "n": 5878, "h": "99e410c1fb511d1c", "c": "# GitHub Actions Workflows\n\nThis directory contains the GitHub Actions workflows for the NOFX project.\n\n## 📚 Documentation Index\n\n- **[README.md](./README.md)** - This file, overview of all workflows\n- **[PERMISSIONS.md](./PERMISSIONS.md)** - Detailed permission analysis and security model\n- **[TRIGGERS.md](./TRIGGERS.md)** - Comparison of event triggers (pull_request vs pull_request_target vs workflow_run)\n- **[FORK_PR_FLOW.md](./FORK_PR_FLOW.md)** - Complete analysis of what happens when a fork PR is submitted\n- **[FLOW_DIAGRAM.md](./FLOW_DIAGRAM.md)** - Visual flow diagrams and quick reference\n\n## 🚀 Quick Start\n\n**Want to understand how fork PRs work?** → Read [FLOW_DIAGRAM.md](./FLOW_DIAGRAM.md)\n\n**Need security details?** → Read [PERMISSIONS.md](./PERMISSIONS.md)\n\n**Confused about triggers?** → Read [TRIGGERS.md](./TRIGGERS.md)\n\n## PR Check Workflows\n\nWe use a **two-workflow pattern** to safely handle PR checks from both internal and fork PRs:\n\n### 1. `pr-checks-run.yml` - Execute Checks\n\n**Trigger:** On pull request (opened, synchronize, reopened)\n\n**Permissions:** Read-only\n\n**Purpose:** Executes all PR checks with read-only permissions, making it safe for fork PRs.\n\n**What it does:**\n- ✅ Checks PR title format (Conventional Commits)\n- ✅ Calculates PR size\n- ✅ Runs backend checks (Go formatting, vet, tests)\n- ✅ Runs frontend checks (linting, type checking, build)\n- ✅ Saves all results as artifacts\n\n**Security:** Safe for fork PRs because it only has read permissions and cannot access secrets or modify the repository.\n\n### 2. `pr-checks-comment.yml` - Post Results\n\n**Trigger:** When `pr-checks-run.yml` completes (workflow_run)\n\n**Permissions:** Write (pull-requests, issues)\n\n**Purpose:** Posts check results as PR comments, running in the main repository context.\n\n**What it does:**\n- ✅ Downloads artifacts from `pr-checks-run.yml`\n- ✅ Reads check results\n- ✅ Posts a comprehensive comment to the PR\n\n**Security:** Safe because:\n- Runs in the main repository context (not fork context)\n- Has write permissions but doesn't execute untrusted code\n- Only reads pre-generated results from artifacts\n\n### 3. `pr-checks.yml` - Strict Checks\n\n**Trigger:** On pull request\n\n**Permissions:** Read + conditional write\n\n**Purpose:** Runs mandatory checks that must pass before PR can be merged.\n\n**What it does:**\n- ✅ Validates PR title (blocks merge if invalid)\n- ✅ Auto-labels PR based on size and files changed (non-fork only)\n- ✅ Runs backend tests (Go)\n- ✅ Runs frontend tests (React/TypeScript)\n- ✅ Security scanning (Trivy, Gitleaks)\n\n**Security:**\n- Fork PRs: Only runs read-only operations (tests, security scans)\n- Non-fork PRs: Can add labels and comments\n- Uses `continue-on-error` for operations that may fail on forks\n\n## Why Two Workflows for PR Checks?\n\n### The Problem\n\nWhen a PR comes from a forked repository:\n- GitHub restricts `GITHUB_TOKEN` permissions for security\n- Fork PRs cannot write comments, add labels, or access secrets\n- This prevents malicious contributors from:\n - Stealing repository secrets\n - Modifying workflow files to execute malicious code\n - Spamming issues/PRs with automated comments\n\n### The Solution\n\n**Two-Workflow Pattern:**\n\n```\nFork PR Submitted\n ↓\n[pr-checks-run.yml]\n - Runs with read-only permissions\n - Executes all checks safely\n - Saves results to artifacts\n ↓\n[pr-checks-comment.yml]\n - Triggered by workflow_run\n - Runs in main repo context (has write permissions)\n - Downloads artifacts\n - Posts comment with results\n```\n\nThis approach:\n- ✅ Allows fork PRs to run checks\n- ✅ Safely posts results as comments\n- ✅ Prevents security vulnerabilities\n- ✅ Follows GitHub's best practices\n\n### Can workflow_run Comment on Fork PRs?\n\n**Yes! ✅ The permissions are sufficient.**\n\n**Key Understanding:**\n- `workflow_run` executes in the **base repository** context\n- Fork PRs exist in the **base repository** (not in the fork)\n- The base repository's `GITHUB_TOKEN` has write permissions\n- Therefore, `workflow_run` can comment on fork PRs\n\n**Security:**\n- Fork PR code runs in isolated environment (read-only)\n- Comment workflow doesn't execute fork code\n- Only reads pre-generated artifact data\n\n**For detailed permission analysis, see:** [PERMISSIONS.md](./PERMISSIONS.md)\n\n## Workflow Comparison\n\n| Workflow | Fork PRs | Write Access | Blocks Merge | Purpose |\n|----------|----------|--------------|--------------|---------|\n| `pr-checks-run.yml` | ✅ Yes | ❌ No | ❌ No | Advisory checks |\n| `pr-checks-comment.yml` | ✅ Yes | ✅ Yes* | ❌ No | Post results |\n| `pr-checks.yml` | ✅ Yes | ⚠️ Partial | ✅ Yes | Mandatory checks |\n\n\\* Write access only in main repo context, not available to fork PR code\n\n## File History\n\n- `pr-checks-advisory.yml.old` - Old advisory workflow that failed on fork PRs (deprecated)\n- Now replaced by the two-workflow pattern (`pr-checks-run.yml` + `pr-checks-comment.yml`)\n\n## Testing the Workflows\n\n### Test with a Fork PR\n\n1. Fork the repository\n2. Make changes in your fork\n3. Create a PR to the main repository\n4. Observe:\n - `pr-checks-run.yml` runs successfully with read-only access\n - `pr-checks-comment.yml` posts results as a comment\n - `pr-checks.yml` runs tests but skips labeling\n\n### Test with a Branch PR\n\n1. Create a branch in the main repository\n2. Make changes\n3. Create a PR\n4. Observe:\n - All workflows run with full permissions\n - Labels are added automatically\n - Comments are posted\n\n## References\n\n- [GitHub Actions: Keeping your GitHub Actions and workflows secure Part 1](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)\n- [Safely posting comments from untrusted workflows](https://securitylab.github.com/research/github-actions-building-blocks/)\n- [GitHub Actions: workflow_run trigger](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)\n"}, "90030e2c28014c001fa0a69b7d829465e278edfa": {"t": 1785759302.936769, "n": 1751, "h": "eb3e8cf0b6549594", "c": "# GitHub Actions Workflows\n\nThis directory contains automated workflows for the NOFX project.\n\n## Workflows\n\n### `translate-issues.yml` - Auto Translate Issues\n\nAutomatically translates GitHub issues between Chinese and English using DeepSeek API.\n\n**Features:**\n- ✅ Detects issue language (Chinese/English)\n- ✅ Translates to the opposite language\n- ✅ Adds translation as a comment\n- ✅ Preserves markdown formatting, code blocks, and links\n- ✅ Cost-effective (uses DeepSeek API)\n\n**How it works:**\n1. Triggered when an issue is opened or edited\n2. Detects if the issue is primarily in Chinese or English\n3. Translates to the opposite language using DeepSeek API\n4. Adds the translation as a comment\n\n**Setup:**\n\nThis workflow requires a DeepSeek API key to be configured as a GitHub secret:\n\n1. Get your DeepSeek API key from https://platform.deepseek.com/\n2. Go to repository Settings → Secrets and variables → Actions\n3. Click \"New repository secret\"\n4. Name: `DEEPSEEK_API_KEY`\n5. Value: Your DeepSeek API key\n6. Click \"Add secret\"\n\n**Cost:**\n- DeepSeek API is very affordable (~$0.001 per issue translation)\n- Much cheaper than GPT-4 or Claude\n\n**Skipping translation:**\nIf `DEEPSEEK_API_KEY` is not set, the workflow will skip translation gracefully.\n\n---\n\n### `test.yml` - Test Workflow\n\nRuns backend and frontend tests on push/PR.\n\n**Features:**\n- ✅ Backend tests (Go)\n- ✅ Frontend tests (Vitest)\n- ✅ Non-blocking (won't prevent PR merges)\n\nSee [PR #229](https://github.com/tinkle-community/nofx/pull/229) for details.\n\n---\n\n## Contributing\n\nWhen adding new workflows:\n1. Test locally first if possible\n2. Document the workflow in this README\n3. Add any required secrets to the setup instructions\n4. Make workflows non-blocking unless critical\n"}}}}