Skip to content

Git-Core Protocol v3.0.0 Update#47

Closed
iberi22 wants to merge 1 commit intomainfrom
protocol-update-v3.0.0
Closed

Git-Core Protocol v3.0.0 Update#47
iberi22 wants to merge 1 commit intomainfrom
protocol-update-v3.0.0

Conversation

@iberi22
Copy link
Owner

@iberi22 iberi22 commented Dec 7, 2025

Updates from Git-Core Protocol v3.0.0. Type: workflows. See: https://github.com/iberi22/Git-Core-Protocol/releases/tag/v3.0.0

Summary by CodeRabbit

Release Notes

  • New Features

    • Introduced automated email notification cleanup with hourly scheduling and manual trigger support.
    • Added repository failure monitoring with automatic issue creation and tracking.
    • Implemented protocol update propagation system for distributing changes across repositories via pull requests.
    • Added self-healing workflow to automatically recover from transient failures and report persistent issues.
  • Chores

    • Updated issue and pull request label organization with new Protocol v3.0 labels.

✏️ Tip: You can customize this high-level summary in your review settings.

@iberi22 iberi22 force-pushed the protocol-update-v3.0.0 branch from cb398fb to ced4892 Compare December 7, 2025 07:57
@gemini-code-assist
Copy link

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

@coderabbitai
Copy link

coderabbitai bot commented Dec 7, 2025

Walkthrough

Five GitHub Actions workflows are introduced to automate repository maintenance and error remediation: email notification cleanup (hourly), global repository monitoring with issue creation (30-minute interval), protocol version propagation to target repositories (tag-triggered), self-healing error classification and recovery (post-workflow), and new Protocol v3.0 labels for workflow automation.

Changes

Cohort / File(s) Change Summary
Email Notification Cleanup
​.github/workflows/email-cleanup.yml
New scheduled workflow (hourly) that checks out the repository, sets up Python 3.11 with cached pip, installs email handler dependencies, creates credential/token JSON files from secrets, and executes the email handler script with configurable email limit (default 50).
Self-Healing Automation
​.github/workflows/self-healing.yml, ​.github/workflows/global-self-healing.yml
Two new failure-response workflows: self-healing detects workflow failures, classifies errors (transient, dependency, lint, test, unknown), and conditionally re-runs or creates issues; global-self-healing monitors repository runs every 30 minutes, detects failures, and creates/updates labeled bug issues with run references.
Protocol Propagation
​.github/workflows/protocol-propagation.yml
New workflow triggered on tag push that detects version from VERSION file, clones target repositories via matrix, creates protocol-update branches, applies versioned file updates (workflows, agents, scripts, or full), detects changes, commits, pushes, and creates pull requests with labels and idempotent handling.
Workflow Label Management
​.github/workflows/setup-labels.yml
Adds Protocol v3.0 label group with seven new labels (high-stakes, needs-human, auto-merged, ai-plan, automation, protocol, planner-generated) for workflow automation and autonomy levels.

Sequence Diagrams

sequenceDiagram
    participant GH as GitHub Actions
    participant API as GitHub API
    participant Repo as Target Repository
    
    GH->>API: Check last 10 workflow runs per repo
    API-->>GH: Run data with conclusions
    alt Failure Detected
        GH->>API: Retrieve failed run workflow name
        GH->>API: Query existing "bug" labeled issues
        alt Issue Found
            GH->>API: Update existing issue with run link
            API-->>GH: Issue updated
        else No Issue
            GH->>API: Create new bug issue with run URL
            API-->>GH: Issue created & labeled
        end
    else No Failure
        GH->>GH: Skip issue creation
    end
Loading
sequenceDiagram
    participant GH as GitHub Actions
    participant Src as Source Repository
    participant Tgt as Target Repository
    participant API as GitHub API
    
    GH->>Src: Detect version from VERSION/tag
    Src-->>GH: Version extracted
    
    loop Each Target Repository
        GH->>Tgt: Clone with token
        Tgt-->>GH: Repository cloned
        GH->>GH: Create protocol-update-v{version} branch
        GH->>GH: Apply update type (workflows/agents/scripts/full)
        GH->>GH: Detect git diff for changes
        alt Changes Exist
            GH->>Tgt: Commit & push branch
            Tgt-->>GH: Branch pushed
            GH->>API: Create PR with standardized message
            API-->>GH: PR created
            GH->>API: Attempt label attachment
            API-->>GH: Labels applied (or gracefully handled if exists)
        else No Changes
            GH->>GH: Skip commit/push
        end
    end
Loading
sequenceDiagram
    participant WF as Failed Workflow
    participant SH as Self-Healing
    participant Logs as Logs
    participant GH as GitHub API
    
    WF->>SH: Trigger on failure
    SH->>Logs: Extract run metadata & analyze logs
    Logs-->>SH: Error classified (transient|dependency|lint|test|unknown)
    
    alt Transient Error
        SH->>GH: Trigger re-run of workflow
        GH-->>SH: Re-run initiated
    else Non-Transient
        SH->>GH: Create or update bug issue
        GH-->>SH: Issue created/updated with labels & run URL
    end
Loading

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~35 minutes

Areas requiring focused attention:

  • Token & secret handling: Verify GMAIL_CREDENTIALS and GMAIL_TOKEN in email-cleanup workflow are properly scoped and documented for safe regeneration
  • Matrix job parallelization & failure modes: Confirm protocol-propagation's max-parallel: 3 and fail-fast: false settings align with intended behavior; check idempotency when PRs already exist
  • Conditional step logic: Review global-self-healing's output-driven conditionals and fallback values (e.g., "Unknown Workflow" defaults) for correctness
  • Error classification robustness: In self-healing workflow, verify log parsing for error detection handles varied workflow log formats gracefully
  • Label consistency & usage: Confirm new Protocol v3.0 labels (ai-plan, automation, protocol, etc.) are referenced consistently across workflows and documented for end-users

Poem

🤖✨ Five new workflows emerge from the night,
Healing broken runs and keeping repos right,
Labels guide the way, automation takes flight,
Protocol propagates with measured delight,
GitHub's self-aware—a beautiful sight! 🚀

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Git-Core Protocol v3.0.0 Update' directly corresponds to the main objective of the PR, which is updating from Git-Core Protocol v3.0.0 with workflows propagation as the primary change.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch protocol-update-v3.0.0

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4a1c807 and ced4892.

📒 Files selected for processing (5)
  • .github/workflows/email-cleanup.yml (1 hunks)
  • .github/workflows/global-self-healing.yml (1 hunks)
  • .github/workflows/protocol-propagation.yml (1 hunks)
  • .github/workflows/self-healing.yml (1 hunks)
  • .github/workflows/setup-labels.yml (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
.github/workflows/**

⚙️ CodeRabbit configuration file

.github/workflows/**: Check for:

  • Proper permissions
  • Security best practices
  • Reusable workflow patterns

Files:

  • .github/workflows/email-cleanup.yml
  • .github/workflows/setup-labels.yml
  • .github/workflows/global-self-healing.yml
  • .github/workflows/self-healing.yml
  • .github/workflows/protocol-propagation.yml
🔇 Additional comments (4)
.github/workflows/setup-labels.yml (1)

73-82: Protocol v3.0 labels addition looks good.

The new labels (high-stakes, needs-human, auto-merged, ai-plan, automation, protocol, planner-generated) follow the existing naming convention and color scheme. They integrate cleanly into the label creation flow and will pair well with the self-healing and protocol-propagation workflows downstream.

.github/workflows/email-cleanup.yml (1)

1-77: Email cleanup workflow structure is solid.

The minimal contents: read permission is appropriate. Credential handling via ephemeral runner files is acceptable. Ensure that tools/email-handler/src/main.py exists and handles failures gracefully (the workflow doesn't explicitly check exit codes).

Confirm that the email handler Python script exists and error handling is in place. You may also consider adding explicit error handling in the "Process Notifications" step (line 58) to catch Python script failures.

.github/workflows/global-self-healing.yml (1)

1-89: Global self-healing monitor is well-structured.

Permissions are appropriately scoped, parallelization is thoughtful (max-parallel: 3, fail-fast: false), and error handling with fallbacks is solid. The hardcoded repo matrix is explicit and maintainable as-is.

.github/workflows/protocol-propagation.yml (1)

20-21: Permissions declaration is correct for this workflow design.

This workflow declares contents: read for the source repository, which is appropriate. External repository push and PR operations use a dedicated MULTI_REPO_TOKEN passed via environment variables, which operates independently of the declared GitHub Actions permissions. This is the intended security model: GitHub Actions permissions govern access to the workflow's source repository, while external tokens handle operations on target repositories.

However, two separate security concerns exist:

  1. Force push on line 142: git push --force unconditionally overwrites the remote branch. Use --force-with-lease or add conditional logic to prevent overwriting legitimate commits if the workflow runs concurrently.

  2. Silent clone failure on line 78-79: Clone errors exit with status 0, hiding access failures. Explicitly log and handle failures rather than silently continuing.

Comment on lines +77 to +80
git clone https://github.com/${{ matrix.repo }}.git target-repo || {
echo "Cannot access ${{ matrix.repo }}, skipping..."
exit 0
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Clone failure exits silently instead of failing the job.

When cloning the target repo fails (line 77–80), the step exits with code 0 (success) instead of propagating the error. This hides access issues or network failures from CI logs.

Either fail the step explicitly (to alert that a repo is inaccessible) or use a separate skip flag to log the reason more clearly. Currently, silent success masks problems.

Consider this approach instead:

         git clone https://github.com/${{ matrix.repo }}.git target-repo || {
-          echo "Cannot access ${{ matrix.repo }}, skipping..."
-          exit 0
+          echo "⚠️  Cannot access ${{ matrix.repo }}, skipping..." >&2
+          exit 0  # OK to skip for this matrix job only
         }

Or fail the job:

         git clone https://github.com/${{ matrix.repo }}.git target-repo || {
-          echo "Cannot access ${{ matrix.repo }}, skipping..."
-          exit 0
+          echo "❌ Failed to clone ${{ matrix.repo }}" >&2
+          exit 1
         }

The choice depends on whether unreachable repos are expected. If expected, use the first approach with stderr redirection (>&2) to ensure the skip is logged conspicuously.

📝 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.

Suggested change
git clone https://github.com/${{ matrix.repo }}.git target-repo || {
echo "Cannot access ${{ matrix.repo }}, skipping..."
exit 0
}
git clone https://github.com/${{ matrix.repo }}.git target-repo || {
echo "⚠️ Cannot access ${{ matrix.repo }}, skipping..." >&2
exit 0 # OK to skip for this matrix job only
}
🤖 Prompt for AI Agents
In .github/workflows/protocol-propagation.yml around lines 77–80, the git clone
failure branch currently echoes a message and exits with 0, which makes the job
report success even when cloning fails; change the branch so it either (A)
explicitly fails the step by exiting non‑zero (e.g., exit 1) so CI surfaces the
error, or (B) if unreachable repos are expected, make the skip visible by
writing the message to stderr and still exit 0 (use stderr redirection) and
include a clear log message indicating the repo was skipped; pick one behavior
and update the clone error block accordingly.

Comment on lines +136 to +142
- name: Push Changes
if: steps.package.outputs.has_changes == 'true'
env:
GH_TOKEN: ${{ secrets.MULTI_REPO_TOKEN || secrets.GITHUB_TOKEN }}
run: |
cd target-repo
git push -u origin ${{ steps.package.outputs.branch }} --force
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Unconditional force push creates race condition risk.

Line 142 uses git push --force without conditions or safeguards. If the workflow triggers multiple times concurrently or if the branch exists from a previous run, this could overwrite legitimate commits in the target repository.

Consider using --force-with-lease (safer, fails if branch changed remotely) or verifying the branch state before force-pushing.

Apply this diff for safer behavior:

         cd target-repo
-        git push -u origin ${{ steps.package.outputs.branch }} --force
+        git push -u origin ${{ steps.package.outputs.branch }} --force-with-lease
📝 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.

Suggested change
- name: Push Changes
if: steps.package.outputs.has_changes == 'true'
env:
GH_TOKEN: ${{ secrets.MULTI_REPO_TOKEN || secrets.GITHUB_TOKEN }}
run: |
cd target-repo
git push -u origin ${{ steps.package.outputs.branch }} --force
- name: Push Changes
if: steps.package.outputs.has_changes == 'true'
env:
GH_TOKEN: ${{ secrets.MULTI_REPO_TOKEN || secrets.GITHUB_TOKEN }}
run: |
cd target-repo
git push -u origin ${{ steps.package.outputs.branch }} --force-with-lease
🤖 Prompt for AI Agents
In .github/workflows/protocol-propagation.yml around lines 136 to 142, the
workflow uses an unconditional git push --force which can overwrite remote
changes if multiple runs or existing commits are present; replace the force push
with a safer approach such as using git push --force-with-lease to fail if the
remote branch has been updated, or add a pre-push check to fetch the remote
branch and compare commit SHAs (abort if they differ) before forcing; update the
run step to either use --force-with-lease or implement the
fetch/compare-and-conditional-push logic so the workflow will not blindly
overwrite remote commits.

Comment on lines +9 to +12
permissions:
contents: write
pull-requests: write
issues: write
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Remove unnecessary contents: write permission.

This workflow only reads run logs, creates/updates issues, and re-runs workflows—none of which require write access to repository contents. Removing this permission adheres to the principle of least privilege.

Apply this diff:

 permissions:
-  contents: write
   pull-requests: write
   issues: write
📝 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.

Suggested change
permissions:
contents: write
pull-requests: write
issues: write
permissions:
pull-requests: write
issues: write
🤖 Prompt for AI Agents
.github/workflows/self-healing.yml around lines 9 to 12: remove the unnecessary
"contents: write" permission (it grants write access to repo contents that this
workflow does not need); replace it with "contents: read" or remove the
"contents" entry entirely if not required, keeping "pull-requests: write" and
"issues: write" as-is to adhere to least privilege.

@iberi22 iberi22 closed this Dec 8, 2025
@iberi22 iberi22 deleted the protocol-update-v3.0.0 branch December 8, 2025 05:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant