add auto approve #196
add auto approve #196
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: zhouying7780 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
needs-ok-to-test
|
Hi @zhouying7780. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
WalkthroughAdds a new Git plugin command Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Pre-merge checks and finishing touchesImportant Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (2 inconclusive)
✅ Passed checks (5 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
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: 1
🧹 Nitpick comments (1)
plugins/git/commands/auto-approve.md (1)
162-164: Clarify CI check passing criteria for NEUTRAL and SKIPPED statuses.The implementation accepts CI checks with "NEUTRAL" or "SKIPPED" conclusions as passing conditions. While this is typically sensible (non-blocking checks), consider adding a note explaining why these are treated as acceptable for auto-approval, especially if "SKIPPED" checks might indicate tests that were not run due to configuration or filtering.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to data retention organization setting
📒 Files selected for processing (3)
PLUGINS.md(1 hunks)docs/data.json(1 hunks)plugins/git/commands/auto-approve.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
plugins/git/commands/auto-approve.md
[grammar] ~22-~22: Use a hyphen to join words.
Context: ...have passed 4. Ensures no 'do-not-merge' related labels are present If any condi...
(QB_NEW_EN_HYPHEN)
[style] ~254-~254: This phrase is redundant. Consider writing “details”.
Context: ...tle - All condition statuses (✓ or ✗) - Specific details for failed conditions - Final action ta...
(SPECIFIC_DETAILS)
🪛 markdownlint-cli2 (0.18.1)
plugins/git/commands/auto-approve.md
10-10: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
30-30: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
34-34: Bare URL used
(MD034, no-bare-urls)
79-79: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
260-260: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
273-273: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
286-286: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
306-306: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
310-310: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
323-323: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
327-327: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
341-341: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
345-345: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
361-361: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
365-365: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
379-379: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
383-383: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
397-397: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
401-401: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
411-411: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
415-415: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (3)
docs/data.json (1)
7-12: Well-structured command entry.The new command is properly registered with all required metadata fields and follows the established naming and documentation conventions.
plugins/git/commands/auto-approve.md (1)
83-123: Verify OWNERS file parsing logic handles edge cases.The OWNERS file discovery and parsing logic (lines 83-123) assumes YAML format and relies on directory tree traversal. Consider documenting:
- What happens if an OWNERS file is malformed or uses non-YAML format?
- Are there limits on directory depth traversed?
- How are multiple OWNERS files with conflicting approvers merged (currently appears to be union/aggregate)?
This is important for correctness if the implementation encounters real-world OWNERS files.
PLUGINS.md (1)
122-122: Manual verification required: Confirm no duplicate auto-approve entries exist in PLUGINS.md.The AI summary suggests a possible duplicate insertion of the
/git:auto-approvecommand. Only one entry is visible at line 122 in the provided code snippet. Search the full PLUGINS.md file to confirm this is the only occurrence and that no duplicate exists elsewhere in the file.
| --- | ||
| description: Automatically add 'approve' label to PR when all conditions are met | ||
| argument-hint: [pr-number] | ||
| --- | ||
|
|
||
| ## Name | ||
| git:auto-approve | ||
|
|
||
| ## Synopsis | ||
| ``` | ||
| /git:auto-approve [pr-number] | ||
| ``` | ||
|
|
||
| ## Description | ||
|
|
||
| The `/git:auto-approve` command automates adding the 'approve' label to a pull request when all required conditions are satisfied. This is particularly useful for repositories using the Prow/Tide merge automation system where the 'approve' label is required for automatic merging. | ||
|
|
||
| The command performs comprehensive checks before adding the approve label: | ||
| 1. Verifies the PR author is listed as an approver in OWNERS files | ||
| 2. Confirms the PR has the 'lgtm' label | ||
| 3. Validates all CI tests have passed | ||
| 4. Ensures no 'do-not-merge' related labels are present | ||
|
|
||
| If any condition fails, the command reports which conditions are not met without making any changes. | ||
|
|
||
| ## Implementation | ||
|
|
||
| ### Prerequisites | ||
|
|
||
| **GitHub CLI (gh) Installation** | ||
| - Check if installed: `which gh` | ||
| - If not installed, provide installation instructions: | ||
| - macOS: `brew install gh` | ||
| - Linux: Follow instructions at https://github.com/cli/cli/linux | ||
| - Verify authentication: `gh auth status` | ||
| - If not authenticated: `gh auth login` | ||
|
|
||
| ### Step 1: Determine the PR number | ||
|
|
||
| **If PR number not provided:** | ||
| ```bash | ||
| # Get current branch | ||
| current_branch=$(git branch --show-current) | ||
|
|
||
| # Find PR for current branch | ||
| pr_number=$(gh pr list --head "$current_branch" --json number --jq '.[0].number') | ||
|
|
||
| # If no PR found, fail with message: | ||
| # "Error: No PR found for branch '$current_branch'. Please specify PR number or create a PR first." | ||
| ``` | ||
|
|
||
| **If PR number provided:** | ||
| - Use the provided PR number directly | ||
| - Validate it exists: | ||
| ```bash | ||
| gh pr view $pr_number --json number &> /dev/null | ||
| # If exit code is not 0, fail with message: | ||
| # "Error: PR #$pr_number not found" | ||
| ``` | ||
|
|
||
| ### Step 2: Fetch PR details | ||
|
|
||
| Use GitHub CLI to get comprehensive PR information: | ||
| ```bash | ||
| gh pr view $pr_number --json \ | ||
| number,title,author,state,labels,statusCheckRollup,files \ | ||
| > /tmp/pr-details.json | ||
| ``` | ||
|
|
||
| Extract key information from JSON: | ||
| - `author.login`: PR author username | ||
| - `state`: PR state (must be OPEN) | ||
| - `labels[].name`: All label names on the PR | ||
| - `statusCheckRollup[].status`: CI check statuses | ||
| - `files[].path`: List of changed files | ||
|
|
||
| **Validation:** | ||
| - If PR state is not "OPEN", fail with message: | ||
| ``` | ||
| Error: PR #$pr_number is not open (state: $state) | ||
| ``` | ||
|
|
||
| ### Step 3: Check Condition 1 - Author is an approver | ||
|
|
||
| **Find OWNERS files for changed files:** | ||
|
|
||
| For each file changed in the PR: | ||
| 1. Search for OWNERS files in the file's directory and parent directories up to repository root | ||
| 2. Parse each OWNERS file (YAML format): | ||
| ```yaml | ||
| approvers: | ||
| - username1 | ||
| - username2 | ||
| ``` | ||
|
|
||
| **Collect all approvers:** | ||
| - Aggregate all `approvers` from all OWNERS files found | ||
| - Deduplicate the list | ||
| - Check if `author.login` is in the approvers list | ||
|
|
||
| **Implementation:** | ||
| ```bash | ||
| # For each changed file, find OWNERS files | ||
| changed_files=$(jq -r '.files[].path' /tmp/pr-details.json) | ||
|
|
||
| for file in $changed_files; do | ||
| dir=$(dirname "$file") | ||
|
|
||
| # Search up the directory tree for OWNERS files | ||
| while [ "$dir" != "." ]; do | ||
| if [ -f "$dir/OWNERS" ]; then | ||
| # Parse OWNERS file and extract approvers | ||
| # Add to aggregated list | ||
| fi | ||
| dir=$(dirname "$dir") | ||
| done | ||
|
|
||
| # Check root OWNERS file | ||
| if [ -f "OWNERS" ]; then | ||
| # Parse and add approvers | ||
| fi | ||
| done | ||
| ``` | ||
|
|
||
| **Result:** | ||
| - Set `is_approver=true` if author is found in any approvers list | ||
| - Set `is_approver=false` otherwise | ||
|
|
||
| ### Step 4: Check Condition 2 - PR has 'lgtm' label | ||
|
|
||
| Extract labels from PR details: | ||
| ```bash | ||
| labels=$(jq -r '.labels[].name' /tmp/pr-details.json) | ||
| ``` | ||
|
|
||
| Check for 'lgtm' label: | ||
| ```bash | ||
| if echo "$labels" | grep -q '^lgtm$'; then | ||
| has_lgtm=true | ||
| else | ||
| has_lgtm=false | ||
| fi | ||
| ``` | ||
|
|
||
| **Result:** | ||
| - Set `has_lgtm=true` if 'lgtm' label is present | ||
| - Set `has_lgtm=false` otherwise | ||
|
|
||
| ### Step 5: Check Condition 3 - All CI tests passed | ||
|
|
||
| Extract CI check statuses: | ||
| ```bash | ||
| # Get all check statuses | ||
| check_statuses=$(jq -r '.statusCheckRollup[]? | "\(.name):\(.status):\(.conclusion)"' /tmp/pr-details.json) | ||
| ``` | ||
|
|
||
| Analyze check statuses: | ||
| - **Status values**: QUEUED, IN_PROGRESS, COMPLETED | ||
| - **Conclusion values**: SUCCESS, FAILURE, NEUTRAL, CANCELLED, SKIPPED, TIMED_OUT, ACTION_REQUIRED | ||
|
|
||
| **Pass conditions:** | ||
| - All checks must have status "COMPLETED" | ||
| - All completed checks must have conclusion "SUCCESS" or "NEUTRAL" or "SKIPPED" | ||
| - No checks with conclusion "FAILURE", "CANCELLED", or "TIMED_OUT" | ||
|
|
||
| **Special cases:** | ||
| - If no checks are defined, consider as passing (set `all_tests_passed=true`) | ||
| - If checks are still running (status != COMPLETED), consider as not passed | ||
|
|
||
| **Implementation:** | ||
| ```bash | ||
| all_tests_passed=true | ||
| failed_checks="" | ||
|
|
||
| while IFS=':' read -r name status conclusion; do | ||
| if [ "$status" != "COMPLETED" ]; then | ||
| all_tests_passed=false | ||
| failed_checks="$failed_checks\n - $name: $status" | ||
| elif [ "$conclusion" != "SUCCESS" ] && [ "$conclusion" != "NEUTRAL" ] && [ "$conclusion" != "SKIPPED" ]; then | ||
| all_tests_passed=false | ||
| failed_checks="$failed_checks\n - $name: $conclusion" | ||
| fi | ||
| done <<< "$check_statuses" | ||
| ``` | ||
|
|
||
| **Result:** | ||
| - Set `all_tests_passed=true` if all checks passed | ||
| - Set `all_tests_passed=false` otherwise | ||
| - Capture `failed_checks` for reporting | ||
|
|
||
| ### Step 6: Check Condition 4 - No 'do-not-merge' labels | ||
|
|
||
| Check for any labels containing 'do-not-merge': | ||
| ```bash | ||
| do_not_merge_labels=$(echo "$labels" | grep -i 'do-not-merge' || true) | ||
|
|
||
| if [ -z "$do_not_merge_labels" ]; then | ||
| no_dnm_labels=true | ||
| else | ||
| no_dnm_labels=false | ||
| fi | ||
| ``` | ||
|
|
||
| Common 'do-not-merge' label patterns to check: | ||
| - `do-not-merge` | ||
| - `do-not-merge/hold` | ||
| - `do-not-merge/work-in-progress` | ||
| - `do-not-merge/invalid-owners-file` | ||
| - Any label containing "do-not-merge" | ||
|
|
||
| **Result:** | ||
| - Set `no_dnm_labels=true` if no do-not-merge labels found | ||
| - Set `no_dnm_labels=false` otherwise | ||
| - Capture `do_not_merge_labels` for reporting | ||
|
|
||
| ### Step 7: Evaluate all conditions and take action | ||
|
|
||
| **Check all conditions:** | ||
| ```bash | ||
| if [ "$is_approver" = true ] && \ | ||
| [ "$has_lgtm" = true ] && \ | ||
| [ "$all_tests_passed" = true ] && \ | ||
| [ "$no_dnm_labels" = true ]; then | ||
| # All conditions met - add approve label | ||
| can_approve=true | ||
| else | ||
| # Conditions not met - report status | ||
| can_approve=false | ||
| fi | ||
| ``` | ||
|
|
||
| **If can_approve=true:** | ||
| 1. Check if 'approve' label already exists: | ||
| ```bash | ||
| if echo "$labels" | grep -q '^approve$'; then | ||
| # Already approved | ||
| else | ||
| # Add approve label | ||
| gh pr edit $pr_number --add-label approve | ||
| fi | ||
| ``` | ||
|
|
||
| 2. Report success | ||
|
|
||
| **If can_approve=false:** | ||
| - Report which conditions are not met | ||
| - Do not add the approve label | ||
|
|
||
| ### Step 8: Generate report | ||
|
|
||
| Create a detailed status report showing: | ||
| - PR number and title | ||
| - All condition statuses (✓ or ✗) | ||
| - Specific details for failed conditions | ||
| - Final action taken | ||
|
|
||
| ## Return Value | ||
|
|
||
| **Success (all conditions met, approve label added):** | ||
| ``` | ||
| ✓ Auto-approve check for PR #1234: "Add new feature" | ||
|
|
||
| Conditions: | ||
| ✓ Author is an approver (found in OWNERS files) | ||
| ✓ PR has 'lgtm' label | ||
| ✓ All CI tests passed (15/15 checks) | ||
| ✓ No 'do-not-merge' labels | ||
|
|
||
| Action: Added 'approve' label to PR #1234 | ||
| ``` | ||
|
|
||
| **Success (already approved):** | ||
| ``` | ||
| ✓ Auto-approve check for PR #1234: "Add new feature" | ||
|
|
||
| Conditions: | ||
| ✓ Author is an approver (found in OWNERS files) | ||
| ✓ PR has 'lgtm' label | ||
| ✓ All CI tests passed (15/15 checks) | ||
| ✓ No 'do-not-merge' labels | ||
|
|
||
| Action: PR #1234 already has 'approve' label | ||
| ``` | ||
|
|
||
| **Failure (conditions not met):** | ||
| ``` | ||
| ✗ Auto-approve check for PR #1234: "Add new feature" | ||
|
|
||
| Conditions: | ||
| ✗ Author is NOT an approver | ||
| - Author: user123 | ||
| - Approvers found in OWNERS: alice, bob, charlie | ||
| ✓ PR has 'lgtm' label | ||
| ✗ CI tests not all passed | ||
| - api-tests: FAILURE | ||
| - integration-tests: IN_PROGRESS | ||
| - unit-tests: SUCCESS | ||
| ✓ No 'do-not-merge' labels | ||
|
|
||
| Action: Cannot add 'approve' label - conditions not met | ||
| ``` | ||
|
|
||
| ## Examples | ||
|
|
||
| 1. **Auto-approve current branch PR** (all conditions met): | ||
| ``` | ||
| /git:auto-approve | ||
| ``` | ||
| Output: | ||
| ``` | ||
| ✓ Auto-approve check for PR #1234: "Fix authentication bug" | ||
|
|
||
| Conditions: | ||
| ✓ Author (alice) is an approver (found in OWNERS, pkg/auth/OWNERS) | ||
| ✓ PR has 'lgtm' label | ||
| ✓ All CI tests passed (8/8 checks) | ||
| ✓ No 'do-not-merge' labels | ||
|
|
||
| Action: Added 'approve' label to PR #1234 | ||
| ``` | ||
|
|
||
| 2. **Specify PR number** (conditions not met): | ||
| ``` | ||
| /git:auto-approve 5678 | ||
| ``` | ||
| Output: | ||
| ``` | ||
| ✗ Auto-approve check for PR #5678: "Add experimental feature" | ||
|
|
||
| Conditions: | ||
| ✓ Author (bob) is an approver (found in OWNERS) | ||
| ✓ PR has 'lgtm' label | ||
| ✓ All CI tests passed (12/12 checks) | ||
| ✗ Has 'do-not-merge' labels: | ||
| - do-not-merge/work-in-progress | ||
|
|
||
| Action: Cannot add 'approve' label - remove do-not-merge labels first | ||
| ``` | ||
|
|
||
| 3. **CI tests still running**: | ||
| ``` | ||
| /git:auto-approve | ||
| ``` | ||
| Output: | ||
| ``` | ||
| ✗ Auto-approve check for PR #9012: "Update dependencies" | ||
|
|
||
| Conditions: | ||
| ✓ Author (charlie) is an approver (found in OWNERS, vendor/OWNERS) | ||
| ✓ PR has 'lgtm' label | ||
| ✗ CI tests not all passed: | ||
| - unit-tests: SUCCESS | ||
| - integration-tests: IN_PROGRESS | ||
| - e2e-tests: QUEUED | ||
| ✓ No 'do-not-merge' labels | ||
|
|
||
| Action: Cannot add 'approve' label - wait for CI tests to complete | ||
| ``` | ||
|
|
||
| 4. **Author not an approver**: | ||
| ``` | ||
| /git:auto-approve | ||
| ``` | ||
| Output: | ||
| ``` | ||
| ✗ Auto-approve check for PR #3456: "Documentation update" | ||
|
|
||
| Conditions: | ||
| ✗ Author (contributor123) is NOT an approver | ||
| - Approvers found in OWNERS: alice, bob, charlie, diana | ||
| ✓ PR has 'lgtm' label | ||
| ✓ All CI tests passed (5/5 checks) | ||
| ✓ No 'do-not-merge' labels | ||
|
|
||
| Action: Cannot add 'approve' label - author needs approval from: alice, bob, charlie, or diana | ||
| ``` | ||
|
|
||
| 5. **Missing lgtm label**: | ||
| ``` | ||
| /git:auto-approve | ||
| ``` | ||
| Output: | ||
| ``` | ||
| ✗ Auto-approve check for PR #7890: "Refactor API handlers" | ||
|
|
||
| Conditions: | ||
| ✓ Author (diana) is an approver (found in pkg/api/OWNERS) | ||
| ✗ PR does NOT have 'lgtm' label | ||
| - Current labels: size/L, kind/cleanup | ||
| ✓ All CI tests passed (10/10 checks) | ||
| ✓ No 'do-not-merge' labels | ||
|
|
||
| Action: Cannot add 'approve' label - needs code review and 'lgtm' label first | ||
| ``` | ||
|
|
||
| 6. **No PR found for current branch**: | ||
| ``` | ||
| /git:auto-approve | ||
| ``` | ||
| Output: | ||
| ``` | ||
| Error: No PR found for branch 'feature/new-api' | ||
|
|
||
| Please either: | ||
| - Create a PR first with: gh pr create | ||
| - Specify a PR number: /git:auto-approve <pr-number> | ||
| - Switch to a branch with an existing PR | ||
| ``` | ||
|
|
||
| 7. **All conditions met, but already approved**: | ||
| ``` | ||
| /git:auto-approve 4321 | ||
| ``` | ||
| Output: | ||
| ``` | ||
| ✓ Auto-approve check for PR #4321: "Performance improvements" | ||
|
|
||
| Conditions: | ||
| ✓ Author (eve) is an approver (found in pkg/performance/OWNERS) | ||
| ✓ PR has 'lgtm' label | ||
| ✓ All CI tests passed (20/20 checks) | ||
| ✓ No 'do-not-merge' labels | ||
|
|
||
| Current labels: lgtm, approve, size/XL, kind/performance | ||
|
|
||
| Action: PR #4321 already has 'approve' label - no action needed | ||
| ``` | ||
|
|
||
| ## Arguments | ||
|
|
||
| - **pr-number** (optional): The pull request number to check and potentially approve. If not provided, the command will find the PR associated with the current git branch. | ||
|
|
||
| ## Notes | ||
|
|
||
| - This command requires the GitHub CLI (`gh`) to be installed and authenticated | ||
| - The command only adds the 'approve' label; it does not trigger merges (that's handled by Prow/Tide) | ||
| - OWNERS files must be in YAML format with an `approvers` field | ||
| - The author check looks for the PR author's GitHub username in any OWNERS file related to changed files | ||
| - CI checks include all GitHub Actions, status checks, and required checks | ||
| - The command is safe to run multiple times; it won't duplicate labels |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Fix markdown formatting and linting violations.
The documentation contains multiple style issues that should be resolved to maintain consistency with repository standards:
- Missing language specifications (22 instances): Fenced code blocks at lines 10, 79, 260, 273, 286, 306, 310, 323, 327, 341, 345, 361, 365, 379, 383, 397, 401, 411, 415 and others lack language identifiers (e.g.,
```bashinstead of```) - Line 30: Replace emphasis formatting with a proper markdown heading (use
###instead of**...**) - Line 34: Wrap bare URL in angle brackets:
<https://github.com/cli/cli/linux> - Line 22: Change "related labels" to "related labels" with proper hyphenation per grammar suggestion
- Line 254: Replace "Specific details" with just "details" to remove redundancy
Apply this diff to fix the most critical issues:
-## Implementation
+### GitHub CLI (gh) Installationand
-```
+```bash
/git:auto-approve [pr-number]
-```
+```bashand
- - Linux: Follow instructions at https://github.com/cli/cli/linux
+ - Linux: Follow instructions at <https://github.com/cli/cli/linux>Please run a markdown linter to identify and fix all remaining code block language specifications throughout the file.
🧰 Tools
🪛 LanguageTool
[grammar] ~22-~22: Use a hyphen to join words.
Context: ...have passed 4. Ensures no 'do-not-merge' related labels are present If any condi...
(QB_NEW_EN_HYPHEN)
[style] ~254-~254: This phrase is redundant. Consider writing “details”.
Context: ...tle - All condition statuses (✓ or ✗) - Specific details for failed conditions - Final action ta...
(SPECIFIC_DETAILS)
🪛 markdownlint-cli2 (0.18.1)
10-10: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
30-30: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
34-34: Bare URL used
(MD034, no-bare-urls)
79-79: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
260-260: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
273-273: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
286-286: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
306-306: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
310-310: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
323-323: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
327-327: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
341-341: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
345-345: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
361-361: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
365-365: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
379-379: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
383-383: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
397-397: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
401-401: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
411-411: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
415-415: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
|
Do we get any value out of this for the tokens we'll spend / nondeterminism we introduce? |
openshift-merge-robot
added
the
needs-rebase
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
3 participants
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes
Special notes for your reviewer:
Checklist:
Summary by CodeRabbit
Release Notes
New Features
/git:auto-approve [pr-number]command to the Git plugin for automatically approving pull requests when all required conditions are met: PR author is an approver, PR has lgtm label, CI checks pass, and no do-not-merge labels present.Documentation
✏️ Tip: You can customize this high-level summary in your review settings.