DEV Community: K@zuki.

How I Built E2E Tests for Chrome Extensions Using Playwright and CDP

K@zuki. — Sun, 13 Jul 2025 10:15:32 +0000

End-to-End Testing for Chrome Extensions with Playwright

The rainy days continue, but it's the perfect season for indoor coding, isn't it?
I'm K@zuki..

How do you test your Chrome extensions?

To be honest, when it comes to E2E testing for Chrome extensions, you might think: "Is it even possible?", "Is it necessary?", "Sounds complicated..."
I thought the same at first.

But when I actually tried it, it turned out to be surprisingly doable.
Moreover, by combining Playwright with Chrome DevTools Protocol (CDP), I found that you can write quite practical tests.

Today, I'd like to share the E2E testing approach I implemented for my Chrome extension called Snack Time.

corrupt952 / SnackTime

Snack Time

The repository for chrome extension to remind you to take a break and have a snack.

Installation

Install this extension from the Chrome Web Store.

Development

Prerequisites

asdf or compatible .tool-versions file

Setup

Install Node.js
```
asdf install
```
Install pnpm
```
npm install -g pnpm
```

Debugging

This extension is developed using CRXJS. So, if you run pnpm dev and load the output directory as an extension, the file will be updated in real time. OUTPUT_DIR is the directory where the output will be placed.

When modifying Content.tsx (Timer component), hot reload may not work properly. In this case, you need to restart the extension:

Go to chrome://extensions

Find "Snack Time" extension

Click the reload button (↻) or toggle the extension off and on

This is a known limitation of Chrome Extension's content scripts.

Install dependencies
```
pnpm install
```

Run the development server

OUTPUT_DIR=~/Documents/snack-time pnpm dev

Load the extension…

View on GitHub

Summary

You can write E2E tests for Chrome extensions using Playwright
Everything, including popups, can be accessed as web pages
Integration tests between popups and content scripts are achievable with CDP
Page Object Pattern makes test code maintainable
bringToFront() enables smooth switching between multiple windows

Why E2E Testing for Chrome Extensions is Challenging

First, let's organize the unique challenges of Chrome extensions.
Compared to regular web applications, Chrome extensions have several special circumstances.

Multiple Execution Contexts

Chrome extensions actually run in multiple "worlds":

Popup - The screen that appears when you click the extension icon
Content Scripts - Scripts injected into each web page
Options Page - Settings screen
Background - Scripts running in the background (Service Worker)
Other custom pages

Since these work together, it seems difficult to test with simple E2E tests.

The Peculiarity of Popups

One of the challenges when wanting to perform E2E testing for Chrome extensions is "not knowing how to interact with popups."
Many Chrome extensions require users to click the extension button in the toolbar and then click elements within the popup to trigger events.
However, Playwright and similar tools cannot normally access this toolbar, which makes it seem difficult.

Extension-Specific URLs

Chrome extension pages have special URLs like chrome-extension://[extension-id]/popup.html.
This extension ID changes depending on the environment, so you can't hardcode it.

Solving with Playwright

Now, let's get to the main topic.
Actually, Playwright can solve these problems quite elegantly.

💡 Any tool using the same driver should be capable of this.

Basic Setup

First, let's look at how to load a Chrome extension with Playwright.

// e2e/fixtures/extension.ts
export const test = base.extend<{
  context: BrowserContext;
  extensionId: string;
}>({
  context: async ({}, use) => {
    const pathToExtension = path.join(__dirname, "../../dist");
    const context = await chromium.launchPersistentContext("", {
      headless: false, // Extensions don't work in headless mode
      args: [
        `--disable-extensions-except=${pathToExtension}`,
        `--load-extension=${pathToExtension}`
      ],
    });
    await use(context);
    await context.close();
  },
  extensionId: async ({ context }, use) => {
    // Dynamically get the extension ID
    const page = await context.newPage();
    await page.goto("chrome://extensions/");
    await page.click("cr-toggle#devMode");

    const extensionCard = await page.locator("extensions-item").first();
    const extensionId = await extensionCard.getAttribute("id");

    await page.close();
    await use(extensionId);
  },
});

By preparing this fixture and reusing it in each test, we can handle the issue of dynamically changing IDs.

Key points:

Use launchPersistentContext to load the extension
Dynamically retrieve the extension ID from chrome://extensions/
Define as a fixture so it can be reused across all tests

Opening Popups as Separate Pages

Here's the crucial point: by opening the popup as a regular page, we can avoid the freeze issue.

// Open the popup as a new page
const popupPage = await context.newPage();
await popupPage.goto(`chrome-extension://${extensionId}/popup/index.html`);

// Now you can test it like a normal page!
await popupPage.click('button:has-text("5:00")');

Well, it's different from actual user interaction, but it's sufficient for functional testing.

Controlling Multi-Window with CDP

Next, let's talk about switching between popups and content pages.

In Snack Time, the timer specified in the popup is displayed within the content page.
Even if you try to test such a mechanism, you can't test it by operating in the tab where the popup is open because the active tab is not the content page.

This is where Chrome DevTools Protocol (CDP) comes in handy for finer browser control.
Page.bringToFront is particularly useful as it brings a specific page to the front, allowing you to switch the active tab.

// content-timer.page.ts - bringToFront implementation
async bringToFront(): Promise<void> {
  const client = await this.page.context().newCDPSession(this.page);
  await client.send("Page.bringToFront");
}

With this mechanism, you can write tests like this:

test("Set timer from popup", async ({ extensionId, context, page }) => {
  // 1. Open the test target page
  await page.goto("https://example.com");
  const contentPage = new ContentTimerPage(page);

  // 2. Open the popup
  const popupPageHandle = await context.newPage();
  const popupPage = new PopupPage(popupPageHandle, extensionId);
  await popupPage.open();

  // 3. Bring content page to front (using CDP)
  await contentPage.bringToFront();

  // 4. Set timer in popup
  await popupPage.clickPresetButton("5");

  // 5. Verify timer is displayed on content page
  await contentPage.waitForTimer();
  await contentPage.verifyTimerVisible();
});

The great thing is that we can test in a way that's close to actual user operations.

sequenceDiagram
    participant Test as Test Code
    participant Popup as Popup Page<br/>(New Tab)
    participant CDP as Chrome DevTools Protocol
    participant Content as Content Page<br/>(example.com)
    participant Timer as Timer Element<br/>(#snack-time-root)

    Test->>Content: 1. Open example.com
    Test->>Popup: 2. Open popup in new tab<br/>chrome-extension://id/popup.html
    Test->>CDP: 3. bringToFront()<br/>(Content Page)
    CDP->>Content: 4. Make content page active
    Test->>Popup: 5. Click preset button (5 min)
    Popup->>Timer: 6. Inject timer
    Test->>Timer: 7. waitForSelector("#snack-time-root")
    Test->>Timer: 8. Verify timer display

Organizing with Page Object Pattern

As test code grows, maintenance becomes challenging.
This is where the Page Object Pattern comes in.

// popup.page.ts - Page Object implementation example
export class PopupPage extends BasePage {
  private readonly presetButtonMap = {
    "5": "1:00",
    "10": "3:00", 
    "15": "5:00",
    "25": "10:00",
  };

  async open(): Promise<void> {
    await this.goto(`chrome-extension://${this.extensionId}/popup/index.html`);
  }

  async clickPresetButton(minutes: "5" | "10" | "15" | "25"): Promise<void> {
    const timeText = this.presetButtonMap[minutes];
    const button = this.page.locator(`button:has-text("${timeText}")`).first();
    await button.click();
  }

  // Define other actions similarly...
}

This way, test cases can be kept simple.

Practical Test Scenarios

Let me introduce some actual tests I've written.

Independence Test Across Multiple Tabs

Chrome extensions need to work independently for each tab. We can test this too:

test("Independent timers work in different tabs", async ({ extensionId, context }) => {
  // Set timer in tab 1
  const page1 = await context.newPage();
  await page1.goto("https://example.com");
  // ... set timer ...

  // Set different timer in tab 2
  const page2 = await context.newPage();
  await page2.goto("https://www.google.com");
  // ... set timer ...

  // Verify both timers are working independently
  await page1.bringToFront();
  await contentPage1.verifyTimerVisible();

  await page2.bringToFront();
  await contentPage2.verifyTimerVisible();
});

Drag & Drop Test

You can also test user interactions:

async dragTimer(deltaX: number, deltaY: number): Promise<void> {
  await this.timerRoot.hover();
  await this.page.mouse.down();
  await this.page.mouse.move(deltaX, deltaY);
  await this.page.mouse.up();
}

Pitfalls and Solutions

During implementation, I encountered several pitfalls.
Honestly, these are unavoidable challenges.

Waiting for Asynchronous Operations

Chrome extensions have many asynchronous operations, so you need to wait appropriately.
This is fundamental in E2E testing, not just for Chrome extensions, but it's especially important here.

// Wait for timer to appear
async waitForTimer(): Promise<void> {
  await this.page.waitForSelector("#snack-time-root");
}

Can't Use Headless Mode

Chrome extensions don't work in headless mode. You need to set headless: false even in CI.
In CI services like GitHub Actions, you can handle this by using Xvfb.

Pros and Cons of Implementation

Here's what I've learned from actual maintenance:

Item	Content	Rating
Test Feasibility	Popup and content script integration	◎ Achievable
User Operation Reproduction	Some differences from actual operations	△ Compromises needed
Maintainability	Organized with Page Object Pattern	◎ Good
CI/CD Integration	No headless, Xvfb required	△ Additional setup needed
Learning Curve	Need to understand CDP	△ Moderate

Overall, while not perfect, it's sufficiently practical.

Especially with Snack Time using Closed Shadow DOM, operations are difficult.
I'm exploring alternative approaches for this, and I'll write about it if successful.

Conclusion

E2E testing for Chrome extensions is more practical than you might think, isn't it?
Sure, it's not perfect, and there are differences from actual popup behavior.
But being able to write tests that cover major functionality is significant.

Especially being able to test complex behaviors involving multiple contexts and user operation flows provides peace of mind.

When creating Chrome extensions, I encourage you to try E2E testing.
It might feel tedious at first, but once you set it up, it's not that different from regular web apps.

The Snack Time code is available on GitHub, so feel free to reference it if you're interested.

Happy Testing! 🎉

How I Simplified My macOS App's AI Integration by Adding a Python Bridge

K@zuki. — Wed, 18 Jun 2025 14:30:56 +0000

Hello, I'm @corrupt952 .

Previously, I shared how to implement an MCP server in a macOS menu bar application using HTTP/SSE.

K@zuki.

Jun 10 '25

Implementing MCP Server in a macOS Menu Bar Application

#swift #ai #claudecode #mcp

Comments 2

5 min read

Today, I'd like to share how that architecture has evolved into something more robust and maintainable using FastMCP.

TL;DR

Replaced direct HTTP/SSE implementation with a FastMCP-based Python bridge
Improved security with host validation and access controls
Achieved better Claude Desktop integration using standard stdio communication
Maintained the same user experience while gaining ecosystem compatibility

Why Change What Works?

When I first implemented MCP support in Chimr (my macOS calendar notification app), I went with a pure Swift HTTP/SSE server.
It worked, but as I used it more, several issues became apparent:

Non-standard Implementation: My custom HTTP approach didn't align with how most MCP servers operate
Maintenance Burden: Keeping up with MCP protocol changes meant updating Swift code
Limited Ecosystem Integration: Couldn't easily leverage Python MCP tools and libraries

Simply put, I was swimming against the current of the MCP ecosystem.

The New Architecture

Here's how the system works now:

Claude Desktop <--(stdio)--> chimr.py <--(HTTP)--> Swift App

Instead of Claude Desktop talking directly to my Swift HTTP server, it now communicates with a Python-based FastMCP server that acts as a bridge. This might seem like adding complexity, but it actually simplifies things significantly.

Implementing the FastMCP Server

The heart of the new system is chimr.py. Here's the basic structure:

#!/usr/bin/env uv run --script
# /// script
# dependencies = [
#     "mcp",
#     "aiohttp"
# ]
# ///
"""
Chimr - MCP server for Chimr calendar integration
"""

import asyncio
from contextlib import asynccontextmanager
from typing import Any, Dict, AsyncIterator

import aiohttp
from mcp.server.fastmcp import FastMCP

# Chimr server configuration
CHIMR_HOST = os.getenv("CHIMR_HOST", "127.0.0.1")
CHIMR_PORT = int(os.getenv("CHIMR_PORT", "8080"))

class ChimrConnection:
    def __init__(self, host: str = CHIMR_HOST, port: int = CHIMR_PORT):
        self.host = host
        self.port = port
        self.base_url = f"http://{host}:{port}"
        self.session: Optional[aiohttp.ClientSession] = None

    async def send_request(self, method: str, params: dict = None) -> dict:
        """Send JSON-RPC request to Chimr server"""
        request_data = {
            "jsonrpc": "2.0",
            "method": method,
            "id": 1
        }

        if params:
            request_data["params"] = params

        # ... send HTTP request to Swift app

What's beautiful about FastMCP is how it handles all the MCP protocol complexity. I just focus on defining tools:

@asynccontextmanager
async def server_lifespan(server: FastMCP) -> AsyncIterator[Dict[str, Any]]:
    """Server lifespan management"""
    try:
        await chimr_connection.connect()
        yield {}
    finally:
        await chimr_connection.disconnect()

# Create MCP server with proper lifecycle management
mcp = FastMCP(
    "Chimr",
    description="Chimr calendar integration through the Model Context Protocol",
    lifespan=server_lifespan
)

@mcp.tool()
async def get_today_events() -> str:
    """Get today's calendar events from Chimr"""
    response = await chimr_connection.send_request(
        "tools/call",
        {"name": "get_today_events", "arguments": {}}
    )
    # ... process response

The beauty is that FastMCP handles all the stdio communication, JSON-RPC parsing, and error handling. I just implement the tools.

Swift Side: From Server to Proxy

On the Swift side, the HTTP server remains but with a different purpose. Instead of being the primary MCP server, it's now an internal API that the Python bridge calls:

private func handleHTTPRequest(_ request: HTTPRequest, connection: NWConnection) {
    if request.method == "POST" && request.path == "/" {
        if let body = request.body, let mcpRequest = MCPRequest(from: body) {
            let response = protocolHandler?.handleRequest(mcpRequest)
                ?? MCPResponse(error: MCPError(code: -32603, message: "Internal error"), id: mcpRequest.id)

            sendHTTPResponse(response: response, connection: connection)
        }
    }
}

But here's where it gets interesting - I added security features that weren't in the original implementation.

Enhanced Security

One concern with running an HTTP server (even on localhost) is security. The new implementation adds several layers of protection:

private func isConnectionAllowed(_ connection: NWConnection) -> Bool {
    let settings = AppSettings.shared

    // If external access is allowed, accept all connections
    if settings.mcpAllowExternalAccess {
        return true
    }

    // Check if the remote endpoint is in the allowed hosts
    guard case .hostPort(let host, _) = connection.endpoint else {
        return false
    }

    switch host {
    case .ipv4(let ipv4):
        let address = ipv4.debugDescription
        return settings.mcpAllowedHosts.contains(address)
            || settings.mcpAllowedHosts.contains("localhost")
    case .ipv6(let ipv6):
        let address = ipv6.debugDescription
        return settings.mcpAllowedHosts.contains(address)
            || settings.mcpAllowedHosts.contains("localhost")
    case .name(let name, _):
        return settings.mcpAllowedHosts.contains(name)
    @unknown default:
        return false
    }
}

This allows users to:

Restrict connections to localhost only (default)
Define specific allowed hosts
Enable external access if needed

Benefits of This Approach

After running this architecture for a while, the benefits are clear:

Standard Compliance: Claude Desktop sees a standard stdio-based MCP server
Easy Updates: Protocol changes only require updating the Python bridge
Better Testing: Can test the Swift API independently from MCP
Ecosystem Access: Can leverage Python MCP tools and libraries

Implementation Tips

If you're considering a similar architecture for your macOS app, here are some lessons learned:

1. Handle Connection Lifecycle Properly

FastMCP provides lifecycle hooks - use them:

@asynccontextmanager
async def server_lifespan(server: FastMCP) -> AsyncIterator[Dict[str, Any]]:
    # Setup resources
    await setup_connections()
    yield {}
    # Cleanup
    await cleanup_connections()

2. Error Handling at the Bridge

The Python bridge should handle errors gracefully:

try:
    response = await chimr_connection.send_request(method, params)
    if "result" in response:
        return response["result"]
    return {"error": "No result returned"}
except Exception as e:
    logger.error(f"Error in {method}: {e}")
    return {"error": str(e)}

3. Keep the Swift API Simple

Your Swift HTTP server doesn't need all the MCP complexity anymore:

struct MCPRequest {
    let method: String
    let params: [String: Any]?
    let id: Any
}

// Just handle tool calls, not the full MCP protocol

Comparing Architectures

Looking back at both implementations:

Aspect	HTTP/SSE Direct	FastMCP Bridge
Complexity	High in Swift	Low in both
Maintenance	Difficult	Easy
Standards	Custom	MCP-compliant
Security	Basic	Enhanced
Testing	Complex	Modular

What's Next?

This architecture opens up interesting possibilities:

Multiple Bridges: Could add Node.js or Rust bridges for different use cases
Remote Deployment: The Swift app could run on a different machine
Plugin System: Other apps could integrate with Chimr through the same API

Conclusion

Sometimes the best solution isn't the most direct one. By adding a Python bridge layer, I actually simplified the overall system while gaining standard compliance and better security.

If you're building MCP support into your macOS app, consider whether a bridge architecture might work better than direct implementation. The initial setup might seem more complex, but the long-term benefits are worth it.

Have you implemented MCP in a native application?
What architecture did you choose? Let me know in the comments!

Implementing MCP Server in a macOS Menu Bar Application

K@zuki. — Tue, 10 Jun 2025 12:03:41 +0000

This article contains some sections partially generated by LLM

Hello, I'm K@zuki, and I have some content stockpiled that I'd like to release at some point.

This is my first post in a while, and it's about implementing an MCP Server in a custom macOS menu bar resident app I've been developing. But rather than explain everything upfront, it's better to just show you what I've built:

// Detect dark theme var iframe = document.getElementById('tweet-1932208018906829040-437'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1932208018906829040&theme=dark" }

Originally, I had implemented functionality in the resident app that could replace arbitrary strings with fullscreen notifications. I've now made this available as an MCP Server, allowing it to be used as a notification system when work is completed in Claude Code.

TL;DR

Implemented HTTP Server instead of CLI tool in the resident app
There are some security risks that need to be considered and addressed

Why Integrate MCP Server into an Existing App

Simply put, it was driven by curiosity and interest. While a typical MCP Server would just require writing a CLI tool, in this case, by integrating an SSE-based MCP Server into an existing app, I can:

Control the app itself
Change app settings

These operations can be called from MCP Clients like Claude Code, Cursor, or Claude Desktop. Additionally, I can leverage specific parts of the app (like fullscreen notifications), which can be quite convenient in certain scenarios.

Implementation Approach

There are several patterns for implementing MCP Server, but currently there are roughly two main types:

CLI
HTTP/SSE

Generally, servers are implemented as CLI tools, and thinking about it now, implementing as CLI would probably be the safer choice. However, since setting up listening on the resident app side seemed cumbersome, I decided to quickly set up an HTTP Server instead.

How It Works

The general mechanism works as follows:

Call mcp-remote
Send requests to the HTTP Server running in the resident app via mcp-remote
The resident app performs some processing

The flow can be represented in the following sequence diagram:

Since Claude Code and Claude Desktop only support CLI, I'm using mcp-remote to communicate with the HTTP Server.

Implementation

For auto-startup with SwiftUI, define it as follows:

import SwiftUI

@main
struct MyApp: App {
    @StateObject private var mcpServer = SimpleMCPServerWrapper()

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

class SimpleMCPServerWrapper: ObservableObject {
    private let server = SimpleMCPServer()

    init() {
        server.start()
    }

    deinit {
        server.stop()
    }
}

You can make it work by defining the MCP Server as follows. As you can see from the code, this requires more work than initially expected, so it's good to rely on AI assistance as needed.

import Foundation
import Network

// Simple MCP Server implementation example
class SimpleMCPServer {
    private var listener: NWListener?
    private let port: UInt16 = 8080

    func start() {
        let parameters = NWParameters.tcp
        parameters.allowLocalEndpointReuse = true

        guard let listener = try? NWListener(using: parameters, on: NWEndpoint.Port(integerLiteral: port)) else {
            print("Failed to create listener")
            return
        }

        self.listener = listener

        listener.newConnectionHandler = { [weak self] connection in
            self?.handleConnection(connection)
        }

        listener.start(queue: .main)
        print("MCP Server started on port \(port)")
    }

    func stop() {
        listener?.cancel()
        listener = nil
        print("MCP Server stopped")
    }

    private func handleConnection(_ connection: NWConnection) {
        connection.start(queue: .main)

        // Read HTTP request
        connection.receive(minimumIncompleteLength: 1, maximumLength: 65536) { [weak self] data, _, isComplete, error in
            guard let data = data, error == nil else {
                connection.cancel()
                return
            }

            if let request = String(data: data, encoding: .utf8) {
                print("Received request:\n\(request)")

                // Handle SSE connection
                if request.contains("GET /sse") {
                    self?.handleSSEConnection(connection)
                }
                // Handle JSON-RPC request
                else if request.contains("POST /") {
                    self?.handleJSONRPCRequest(connection, requestData: data)
                }
            }

            if isComplete {
                connection.cancel()
            }
        }
    }

    private func handleSSEConnection(_ connection: NWConnection) {
        // Send SSE headers
        let headers = """
        HTTP/1.1 200 OK\r
        Content-Type: text/event-stream\r
        Cache-Control: no-cache\r
        Connection: keep-alive\r
        Access-Control-Allow-Origin: *\r
        \r

        """

        connection.send(content: headers.data(using: .utf8), completion: .contentProcessed { _ in
            print("SSE connection established")
        })

        // Send initial connection event
        let connectEvent = "event: connected\ndata: {\"status\": \"connected\"}\n\n"
        connection.send(content: connectEvent.data(using: .utf8), completion: .contentProcessed { _ in })
    }

    private func handleJSONRPCRequest(_ connection: NWConnection, requestData: Data) {
        // Extract HTTP body (simplified implementation)
        if let requestString = String(data: requestData, encoding: .utf8),
           let bodyStart = requestString.range(of: "\r\n\r\n") {
            let bodyData = String(requestString[bodyStart.upperBound...]).data(using: .utf8) ?? Data()

            // Parse JSON-RPC request
            if let json = try? JSONSerialization.jsonObject(with: bodyData) as? [String: Any],
               let method = json["method"] as? String,
               let id = json["id"] {

                let response: [String: Any]

                switch method {
                case "initialize":
                    response = [
                        "jsonrpc": "2.0",
                        "result": [
                            "protocolVersion": "2024-11-05",
                            "serverInfo": [
                                "name": "simple-mcp-server",
                                "version": "1.0.0"
                            ],
                            "capabilities": [
                                "tools": [:],
                                "resources": [:]
                            ]
                        ],
                        "id": id
                    ]

                case "tools/list":
                    response = [
                        "jsonrpc": "2.0",
                        "result": [
                            "tools": [[
                                "name": "hello",
                                "description": "Returns Hello, World!",
                                "inputSchema": [
                                    "type": "object",
                                    "properties": [:]
                                ]
                            ]]
                        ],
                        "id": id
                    ]

                case "tools/call":
                    if let params = json["params"] as? [String: Any],
                       let toolName = params["name"] as? String,
                       toolName == "hello" {
                        response = [
                            "jsonrpc": "2.0",
                            "result": [
                                "content": [[
                                    "type": "text",
                                    "text": "Hello, World! from MCP Server"
                                ]]
                            ],
                            "id": id
                        ]
                    } else {
                        response = [
                            "jsonrpc": "2.0",
                            "error": [
                                "code": -32601,
                                "message": "Method not found"
                            ],
                            "id": id
                        ]
                    }

                default:
                    response = [
                        "jsonrpc": "2.0",
                        "error": [
                            "code": -32601,
                            "message": "Method not found"
                        ],
                        "id": id
                    ]
                }

                // Send response
                if let responseData = try? JSONSerialization.data(withJSONObject: response),
                   let responseString = String(data: responseData, encoding: .utf8) {

                    let httpResponse = """
                    HTTP/1.1 200 OK\r
                    Content-Type: application/json\r
                    Content-Length: \(responseData.count)\r
                    Access-Control-Allow-Origin: *\r
                    \r
                    \(responseString)
                    """

                    connection.send(content: httpResponse.data(using: .utf8), completion: .contentProcessed { _ in
                        connection.cancel()
                    })
                }
            }
        }
    }
}

Calling from Claude Code

To call from Claude Code, configure it as follows:

{
  "mcpServers": {
    "hello-world": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://localhost:8080/sse"
      ]
    }
  }
}

Once properly configured, you can call it and use the functionality prepared in the app, as shown in the introduction:

// Detect dark theme var iframe = document.getElementById('tweet-1932208018906829040-75'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1932208018906829040&theme=dark" }

Security Considerations

Publishing as an HTTP Server means there are certain security risks that need attention.

1. Localhost Binding

By default, it binds to localhost (127.0.0.1), but accidentally binding to 0.0.0.0 would make it accessible from external sources.

// Safe: localhost only
let listener = try? NWListener(using: parameters, on: NWEndpoint.Port(integerLiteral: port))

// Dangerous: all interfaces
// let listener = try? NWListener(using: parameters, on: NWEndpoint.Port(rawValue: port)!)

2. Lack of Authentication

The current implementation has no authentication functionality, meaning any local process can access the MCP server. Consider implementing authentication as needed:

API key-based authentication
Token-based authentication
Connection source process verification

3. CORS Settings

While not a concern in this case, CORS may need consideration in some scenarios. Access-Control-Allow-Origin: * is convenient for development, but in production environments, you should only allow specific origins rather than leaving it wide open.

4. Input Validation

Properly validate JSON-RPC request input values to prevent injection attacks.

5. Resource Limits

Depending on the app and PC, high load may be a concern, so pay attention to:

Concurrent connection limits
Request size limits
Rate limiting

Conclusion

This post covered integrating MCP Server into a macOS resident app. I'll probably switch to CLI by the time I release it, but please use this as an example for cases where you want to prepare an MCP Server interface for existing resident apps.

By implementing it this way, you can relatively easily turn your own app into an MCP Server. You can also aim for easier configuration changes, utilize features that currently don't reach those itchy spots, and control specific app functions, making it very convenient.

The app with integrated MCP Server is planned to recruit beta testers over the weekend, so if you're interested, keep an eye on Twitter or the blog.

Subtle but Important: IPAddr Behavior Change in Ruby 3.1

K@zuki. — Tue, 10 Sep 2024 14:05:02 +0000

Have you ever encountered a situation where your Ruby code works perfectly fine in one version but behaves differently in another?
Today, let's dive into a subtle yet important change in Ruby's IPAddr class that occurred in version 3.1.

TL;DR

The behavior of IPAddr changed in Ruby 3.1.
IPv4-mapped IPv6 addresses (e.g., ::ffff:127.0.0.1) are no longer considered equivalent to their IPv4 counterparts when compared to IPv4 ranges.
This change can affect code that deals with IP address ranges, particularly in network configurations or access control lists.
A related issue affecting Rails' TRUSTED_PROXIES behavior has been reported: Rails Issue #52862

The Change

In Ruby versions prior to 3.1, when comparing an IPv4 range with an IPv4-mapped IPv6 address, the comparison would return true if the IPv4 part of the address was within the range.
However, this behavior changed in Ruby 3.1.

Let's look at a concrete example:

require 'ipaddr'

ipv4_range = IPAddr.new('127.0.0.0/8')
ipv4_address = '127.0.0.1'
ipv4_mapped_address = '::ffff:127.0.0.1'

puts "Ruby version: #{RUBY_VERSION}"
puts "IPv4 Range === IPv4 Address: #{ipv4_range === ipv4_address}"
puts "IPv4 Range === IPv4-mapped Address: #{ipv4_range === ipv4_mapped_address}"

Running this code in Ruby 3.0 gives us:

# IPv4 Range === IPv4 Address
> IPAddr.new('127.0.0.0/8') === '127.0.0.1'
true

# IPv4 Range === IPv4-mapped Address:
> IPAddr.new('127.0.0.0/8') === '::ffff:127.0.0.1'
true

But in Ruby 3.1 or later:

# IPv4 Range === IPv4 Address
> IPAddr.new('127.0.0.0/8') === '127.0.0.1'
true

# IPv4 Range === IPv4-mapped Address:
> IPAddr.new('127.0.0.0/8') === '::ffff:127.0.0.1'
false

Why Did This Change?

This change was introduced in the ipaddr gem, which is a bundled gem in Ruby.
The specific commit that introduced this change can be found here.

Implications

While this change makes the behavior more technically correct, it can lead to unexpected results in existing code that relies on the previous behavior.
This is particularly relevant for applications that deal with IP address ranges, such as those handling network configurations or access control lists.

For instance, if you're using IPAddr to check if an IP is within a trusted range, you might now need to explicitly handle IPv4-mapped addresses separately.

FYI: https://github.com/rails/rails/issues/52862

How to Handle This in Your Rails Code

If you're using Rails and configuring trusted proxies, you might need to adjust your configuration to account for this change.
Here's how you can handle both IPv4 and IPv4-mapped IPv6 addresses:

config.action_dispatch.trusted_proxies = ActionDispatch::RemoteIp::TRUSTED_PROXIES + [
  # IPv4-mapped IPv6 loopback
  IPAddr.new('::ffff:127.0.0.0/104'),
  # IPv4-mapped IPv6 private network
  IPAddr.new('::ffff:10.0.0.0/104'),
  # other trusted proxies...
]

By explicitly including both IPv4 and IPv4-mapped IPv6 versions of your trusted proxy ranges, you ensure that your Rails application will correctly identify trusted proxies regardless of how they're represented.

Remember to test your configuration thoroughly, especially if you're upgrading from an older version of Ruby or Rails.

Conclusion

This change in IPAddr behavior serves as a reminder of the importance of thorough testing across different Ruby versions, especially when dealing with core functionalities like network addressing.
It also highlights the ongoing efforts in the Ruby community to improve consistency and correctness, even if it sometimes means breaking changes in minor version updates.

Have you encountered any surprising behavior changes in your Ruby upgrades?
How do you usually handle such situations?
Share your experiences in the comments!

Introducing a Custom GitHub Action for Command Retry with Output Capture

K@zuki. — Mon, 19 Aug 2024 03:01:59 +0000

I've published a GitHub Action that I've been using in my work.
It's designed to retry specific commands, which sets it apart from similar actions available in the Marketplace.
The key feature of this action is its ability to capture the command output, which is often a limitation in existing retry actions.

Marketplace

corrupt952 / actions-retry-command

retry-command

Retries an Action step on failure.
This action is unique compared to other actions in that it is possible to obtain the results of retries.

Marketplace

Inputs

`command`

Required

The command to run.

`working_directory`

Required

The directory in which to execute the command.

`max_attempts`

Required

The maximum number of times to attempt the command.
Default is 5.

`retry_interval`

Required

The time to wait between retry attempts, in seconds. Default is 5.
You can also write $((RANDOM % 31)) to make it a random value.

Output

`exit_code`

Exit code of the last command executed

`result`

Output of the last command executed

Example

Simple

- uses: corrupt952/actions-retry-command@v1
  with:
    command: terraform plan -no-color
    max_attempts: 3
    retry_interval: 10

Retry interval to a random time

- uses: corrupt952/actions-retry-command@v1
  with:
    command: terraform plan -no-color
    retry_interval: $((RANDOM % 31))

Set working directory

- uses: corrupt952/actions-retry-command@v1
  with

…

View on GitHub

How to Use

The usage is straightforward.
For example, if you want to retry terraform plan, you can use it like this:

- uses: corrupt952/actions-retry-command@v1
  with:
    command: terraform plan -no-color
    working_directory: ${{ github.workspace }}
    max_attempts: 3
    retry_interval: 10

This will execute the command up to 3 times with a 10-second interval between retries.

Advanced Usage: Random Retry Interval

Since the action is implemented as a shell script, you can easily add randomness to the retry interval:

- uses: corrupt952/retry-command@v1
  with:
    command: terraform plan -no-color
    working_directory: ${{ github.workspace }}
    retry_interval: $((RANDOM % 31))

This will set a random retry interval between 0 and 30 seconds.

Capturing Command Output

The main reason I created this action was to capture the command output.
Here's how you can do that:

- uses: corrupt952/retry-command@v1
  id: terraform_plan
  continue-on-error: true
  with:
    command: terraform plan -no-color
    working_directory: ${{ github.workspace }}
    max_attempts: 3
- if: steps.terraform_plan.outcome == 'failure'
  run: |
    echo "Exit code: ${{ steps.terraform_plan.outputs.exit_code }}"
    echo "Result: ${{ steps.terraform_plan.outputs.result }}"

Currently, the action captures the result of the last successful or failed attempt.

This feature allows you to easily use the results of the retry-command in other actions.
or example, I use this to share Terraform plan results on GitHub, making it simple to review and discuss infrastructure changes within pull requests.

Conclusion

If you need similar functionality in your GitHub Actions workflows, feel free to give this action a try.
It's particularly useful when you need to both retry commands and capture their output.

Easy Notes in VSCode: Scraps

K@zuki. — Thu, 23 May 2024 17:30:31 +0000

Hello, I'm K@zuki..

Today, I want to introduce a new VSCode extension I developed called Scraps. This extension is a handy tool for taking quick notes while coding.

What is `Scraps`?

Scraps is a simple extension that allows you to write notes in the sidebar of VSCode. This extension helps you quickly jot down ideas or reminders that come up during development.

https://marketplace.visualstudio.com/items?itemName=corrupt952.scraps

Key Features

Easy Note Creation: You can write notes directly in the sidebar, making it easy to jot down thoughts quickly.
Save Functionality: Notes are saved even after closing VSCode, so you can safely store your thoughts.
Simple UI: The intuitive editor allows you to input notes in Markdown format.

How to Install

Search for Scraps in the VSCode Extensions marketplace and install it.

You'll see an icon in the Activity Bar that looks like a notepad with a pencil. Click this icon to open the sidebar.

How to Use

Open VSCode and click the Scraps icon in the Activity Bar.
Enter your text freely in the note area displayed in the sidebar.
No special save operation is needed; your notes are automatically saved.

Background of Development

Scraps was born out of my need to take quick notes during daily coding sessions. Although I use other main note-taking tools, I often need to temporarily store notes that don't need to be kept long-term. I developed Scraps to fulfill this need for a simple, VSCode-contained note-taking tool.

Use Cases

Some possible use cases for Scraps include:

Writing notes or tasks that you don't want to include directly in your code.
Temporarily storing commands or tokens until you can save them elsewhere.
Keeping a simple to-do list for the day's tasks.

Conclusion

Scraps is still in its early stages, but I plan to continue adding features and making improvements. If you have any feedback or suggestions, please let me know through the marketplace review section or the GitHub repository.

I hope Scraps enhances your coding experience!

https://github.com/corrupt952/scraps

Easy Notes in VSCode: Scraps

K@zuki. — Thu, 23 May 2024 17:30:31 +0000

Hello, I'm K@zuki..

Today, I want to introduce a new VSCode extension I developed called Scraps. This extension is a handy tool for taking quick notes while coding.

What is `Scraps`?

Scraps is a simple extension that allows you to write notes in the sidebar of VSCode. This extension helps you quickly jot down ideas or reminders that come up during development.

https://marketplace.visualstudio.com/items?itemName=corrupt952.scraps

Key Features

Easy Note Creation: You can write notes directly in the sidebar, making it easy to jot down thoughts quickly.
Save Functionality: Notes are saved even after closing VSCode, so you can safely store your thoughts.
Simple UI: The intuitive editor allows you to input notes in Markdown format.

How to Install

Search for Scraps in the VSCode Extensions marketplace and install it.

You'll see an icon in the Activity Bar that looks like a notepad with a pencil. Click this icon to open the sidebar.

How to Use

Open VSCode and click the Scraps icon in the Activity Bar.
Enter your text freely in the note area displayed in the sidebar.
No special save operation is needed; your notes are automatically saved.

Background of Development

Use Cases

Some possible use cases for Scraps include:

Writing notes or tasks that you don't want to include directly in your code.
Temporarily storing commands or tokens until you can save them elsewhere.
Keeping a simple to-do list for the day's tasks.

Conclusion

I hope Scraps enhances your coding experience!

https://github.com/corrupt952/scraps

Debugging Renovate locally

K@zuki. — Tue, 09 May 2023 22:00:00 +0000

Introduction

If you are using Renovate, it is important to check whether the settings are properly configured.

This article explains how to debug Renovate in a local environment.

Prerequisites

The following prerequisites are required:

Generate GitHub's Classic PAT and set it in the environment variable such as GITHUB_TOKEN.
- If it's only dry-run, read permission to the repository should be sufficient.

Verification Procedure

Just execute the following command:

RENOVATE_CONFIG_FILE=.github/renovate.json5 \
  npx renovate \
    --token=$GITHUB_TOKEN \
    --schedule="" \
    --require-config=ignored \
    --dry-run=full \
    corrupt952/home-apps

You can check whether the target is correct and whether a PR is created by using stats or messages displayed in DRY-RUN.

$ RENOVATE_CONFIG_FILE=.github/renovate.json5 \
    npx renovate \
      --token=$GITHUB_TOKEN \
      --schedule="" \
      --require-config=ignored \
      --dry-run=full \
      corrupt952/home-apps
 INFO: Repository started (repository=corrupt952/home-apps)
       "renovateVersion": "35.71.5"
 INFO: Dependency extraction complete (repository=corrupt952/home-apps, baseBranch=main)
       "stats": {
         "managers": {
           "argocd": {"fileCount": 5, "depCount": 6},
           "kubernetes": {"fileCount": 1, "depCount": 2},
           "regex": {"fileCount": 5, "depCount": 15}
         },
         "total": {"fileCount": 11, "depCount": 23}
       }
 INFO: DRY-RUN: Would ensure Dependency Dashboard (repository=corrupt952/home-apps)
       "title": "Dependency Dashboard"
 INFO: DRY-RUN: Would save repository cache. (repository=corrupt952/home-apps)
 INFO: Repository finished (repository=corrupt952/home-apps)
       "cloned": true,
       "durationMs": 6888

Brief explanation of the command

The following is an explanation of the command mentioned in the verification procedure:

RENOVATE_CONFIG_FILE=.github/renovate.json5
- Specifies the path of the configuration file you want to test the operation of.
- The configuration file contains the information necessary for Renovate to operate.
- For details, refer to the official Renovate documentation.
npx renovate
- Since you want to try renovate easily without installing it individually, you are running renovate using npx.
token=$GITHUB_TOKEN
- Specifies the PAT generated in advance.
- PAT is necessary for Renovate to access the GitHub API.
- For details, refer to the official Renovate documentation.
schedule=""
- Since it may not be executed if the schedule is defined in the settings, an empty string is specified.
require-config=ignored
- Prevents the remote repository's configuration file from being read.
- If the remote repository's configuration file is read, it will be merged with the local configuration file, which may result in unnecessary PRs being generated.
- For details, refer to the official Renovate documentation.
dry-run=full
- It outputs messages to standard output without actually creating, updating, or deleting PRs.
- For details, refer to the official Renovate documentation.
corrupt952/home-apps
- Specifies the repository targeted by Renovate.
- In this example, corrupt952/home-apps is targeted.

Other cases that are likely to occur when verifying the operation

I want to validate a branch other than the default branch.

Execute by specifying RENOVATE_BASE_BRANCHES.

# In the case of targeting the dev branch
RENOVATE_BASE_BRANCHES=dev \
RENOVATE_CONFIG_FILE=.github/renovate.json5 \
  npx renovate \
    --token=$GITHUB_TOKEN \
    --schedule="" \
    --require-config=ignored \
    --dry-run=full \
    corrupt952/home-apps

I want to create a PR.

Confirm that PAT has write permission to the repository and remove the --dry-run option.

RENOVATE_CONFIG_FILE=.github/renovate.json5 \
  npx renovate \
    --token=$GITHUB_TOKEN \
    --schedule="" \
    --require-config=ignored \
    corrupt952/home-apps

Conclusion

This article explained how to debug Renovate locally.

If you are using Renovate, it is important to check whether the settings are properly configured.

Please execute the procedure explained in this article to use Renovate normally.

Change the way you access your home network using Cloudflare Tunnel

K@zuki. — Sun, 07 May 2023 22:00:00 +0000

Introduction

Recently, I changed my access method to my home network using Cloudflare Tunnel. This article will introduce that method.

Old Configuration

Previously, I accessed each service on my home cluster using VPN connections. The following is a diagram of that configuration.

New Configuration

By using Cloudflare Tunnel, I eliminated the need for VPN connections and made it possible to access my home network without direct external exposure.

Pros/Cons

Pros
- No need to expose servers/home networks externally
- Can benefit from Cloudflare CDN (security, IPv6 support, etc.)
- Can restrict access to specific domains or paths
- Can access services from external sources (compared to old configuration)
- No need to set up a VPN server (compared to old configuration)
Cons
- No need to transfer, but need to manage the Apex Domain by Clouflare

Changes in k8s Cluster Configuration

Several changes were required for the new configuration.

Add
- cloudflared ... necessary to tunnel access from Cloudflare
Eliminate
- MetalLB ... not necessary because cloudflared directly accesses each Service
- Nginx Ingress ... same as above

The following article was useful in setting up Cloudflare Tunnel for a home cluster.

Cloudflare Tunnelで自宅サーバーを公開する(FreeプランOK)

zenn.dev

Restricting Access to Specific Domains or Paths

It is possible to restrict access to specific domains or paths, thus improving security.

For example, consider setting up WordPress in a Kubernetes cluster to be accessible from external sources.

In this case, it is possible to only authenticate with Cloudflare Zero Trust for paths starting with /wp-login or /wp-admin, without requiring authentication for normal requests.

Conclusion

This article introduced the change in access method to my home network using Cloudflare Tunnel. This new configuration has benefits such as improved security and IPv6 support. Additionally, it is possible to configure it with security in mind by restricting access to specific domains or paths.

corrupt952 / home-apps

Home k8s manifests

Repository for the home kubernetes cluster.

This repository manages the manifests of the home kubernetes cluster.

⚠️ Archived notice

This repository is archived. It has been moved to corrupt952/home.

Setup Argo CD

helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd --create-namespace --namespace argocd
kubectl -n argocd port-forward deploy/argocd-server 8080:8080
argocd login \
    --insecure \
    --grpc-web \
    --username admin \
    --password "$(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d)" \
    localhost:8080
argocd app create argocd-config \
    --insecure \
    --grpc-web \
    --repo https://github.com/corrupt952/home-apps.git \
    --path argocd-config/base \
    --dest-namespace argocd \
    --dest-server https://kubernetes.default.svc \
    --sync-policy automated \
    --auto-prune \
    --revision main

View on GitHub

Trying Argo CD's Multiple sources

K@zuki. — Sat, 06 May 2023 22:00:00 +0000

Introduction

Argo CD has a feature called Multiple sources.

This feature is in beta, but it allows you to build an application by retrieving configuration elements from different sources such as Helm Chart and Kustomize.

In this article, we will look at how Multiple sources can be useful and how to use it for deploying WordPress.

Benefits of Multiple sources

Multiple sources are useful in the following cases:

Separation of Helm Chart and values.yaml

You can separate the reference to Helm Chart and values.yaml into different repositories or directories.

This makes version management of the application easier.

Managing multiple Helm Charts in one Application

Using Multiple sources, you can manage multiple Helm Charts in one Application.

This allows for more flexible management of the application's configuration.

Deploying WordPress using Multiple sources

Why WordPress?

Bitnami's WordPress Chart has a problem where the DB password is regenerated when the pod is restarted. Therefore, it is necessary to separate the DB from the WordPress Chart, which is perfect for Multiple sources.

Defining an Application for WordPress

Let's use Multiple sources to deploy WordPress.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: wordpress
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  sources:
    # Make corrupt952/home-apps available for $manfiest
    - ref: manifest
      repoURL: https://github.com/corrupt952/home-apps

    # Load resources defined in corrupt952/home-apps/wordpress/base
    # Manage secrets such as passwords used by mariadb and wordpress
    - path: wordpress/base
      repoURL: https://github.com/corrupt952/home-apps

    # Load bitnami/mariadb Chart and corrupt952/home-apps/values/mariadb.yaml
    - chart: mariadb
      repoURL: https://charts.bitnami.com/bitnami
      targetRevision: 12.1.5
      helm:
        releaseName: mariadb
        valueFiles:
        - $manifest/values/mariadb.yaml

    # Load bitnami/wordpress Chart and corrupt952/home-apps/values/wordpress.yaml
    - chart: wordpress
      repoURL: https://charts.bitnami.com/bitnami
      targetRevision: 16.0.4
      helm:
        releaseName: wordpress
        valueFiles:
        - $manifest/values/wordpress.yaml

  ...

By defining the previously source definition as sources, you can define multiple sources.

ref: manifest

The first definition is to refer to values.yaml in corrupt952/home-apps in the second and third sources.

In the case of ref, resources in the repository are not loaded, so it is important to remember to define it when referring to a file.

- ref: manifest
  repoURL: <https://github.com/corrupt952/home-apps>

path: wordpress/base

The second definition is a source that manages resources with kustomize.

Since MariaDB and WordPress need to share passwords, Sealed Secret is used to manage them, and this definition is added to load and create resources.

- path: wordpress/base
  repoURL: <https://github.com/corrupt952/home-apps>

chart: mariadb

The third definition is a source that loads the MariaDB Helm Chart.

valueFiles is defined to refer to values/mariadb.yaml in corrupt952/home-apps.

In the era before Multiple sources, such definitions were not possible, and it was necessary to define Chart.yaml in the same repository as values.yaml.

- chart: mariadb
  repoURL: <https://charts.bitnami.com/bitnami>
  targetRevision: 12.1.5
  helm:
    releaseName: mariadb
    valueFiles:
    - $manifest/values/mariadb.yaml

# values/mariadb.yaml
global:
  storageClass: nfs-client

auth:
  username: wordpress
  database: wordpress
  existingSecret: wordpress-credentials

chart: wordpress

The fourth definition is a source that loads the WordPress Helm Chart.

Like MariaDB, it refers to values/wordpress.yaml in corrupt952/home-apps.

- chart: wordpress
  repoURL: <https://charts.bitnami.com/bitnami>
  targetRevision: 16.0.4
  helm:
    releaseName: wordpress
    valueFiles:
    - $manifest/values/wordpress.yaml

# values/wordpress.yaml
global:
  storageClass: nfs-client

allowEmptyPassword: false
existingSecret: wordpress-credentials

mariadb:
  enabled: false

memcached:
  enabled: false

externalDatabase:
  host: mariadb.wordpress.svc.cluster.local
  user: wordpress
  database: wordpress
  existingSecret: wordpress-credentials

...

Conclusion

We have seen an example of deploying WordPress using Multiple sources. While it is still in beta, using Multiple sources effectively can lead to appropriate separation and commonization of manifests and settings.

Automatically Updating Helm Chart Referenced in Argo CD Using Renovate - Part 2

K@zuki. — Fri, 05 May 2023 19:23:42 +0000

Yesterday, I posted an article titled "Automatically Updating Helm Chart Referenced in Argo CD Using Renovate."

Automatically Updating Helm Charts Referenced by Argo CD with Renovate

K@zuki. ・ May 4 '23

#argocd #renovate #devops #kubernetes

That method used regexManagers to retrieve version information from GitHub releases specified in the configuration. However, this time I will introduce an even easier and simpler method.

Recap of Previous Method

The previous method involved adding regexManagers and comments to the lines to be updated.



  // renovate.json5
  "regexManagers": [
    {
      "datasourceTemplate": "github-releases",
      "fileMatch": [
        "argocd-config/base/.*\\.yaml"
      ],
      "matchStrings": [
        // e.g.) targetRevision: 5.31.0 # renovate: depName=argoproj/argo-helm extractVersion=^argo-cd-(?<version>.+)$
        " +targetRevision: +(?<currentValue>[^'\" ]+) +# renovate: depName=(?<depName>[^ \\n]+) +(extractVersion=(?<extractVersion>[^\\n]+))?",
      ],
    },
  ]



# Add comments to the lines to be updated
targetRevision: 5.31.0 # renovate: depName=argoproj/argo-helm extractVersion=^argo-cd-(?<version>.+)$

This time, we will make the automatic update process even easier.

Making It Easier

Read the Documentation

To make the automatic update process even easier, we first read the documentation for Managers.

docs.renovatebot.com

The reason for reading the documentation for Managers is that if there are already suitable Managers listed in the documentation, then you can simply write the configuration for that Manager and it will automatically become an update target.

If it is not listed, then write regexManagers, create an issue, or submit a pull request.

Looking through the documentation, it seems that there is a Manager called argocd.

docs.renovatebot.com

Although it is not clear whether it can be used as is, the Additional Information section suggests that it may be suitable for Argo CD applications.

The argocd manager has no fileMatch default patterns, so it won't match any files until you configure it with a pattern. This is because there is no commonly accepted file/directory naming convention for argocd YAML files and we don't want to check every single *.yaml file in repositories just in case any of them have ArgoCD definitions.

Define the Configuration

If there is a definition for regexManagers, delete it. Simply define the path to the files to be updated in fileMatch.



  "argocd": {
    "fileMatch": [
      "argocd-config/base/.*\\.yaml",
    ],
  },

FYI: https://github.com/corrupt952/home-apps/blob/main/.github/renovate.json5#L19-L23

Updating the configuration in this way will make it an update target. It is much simpler than the previous method.

PRs Created

chore(deps): update helm release argo-cd to v5.31.1 #39

renovate[bot] posted on May 05, 2023

This PR contains the following updates:

Package	Update	Change
argo-cd	patch	`5.31.0` -> `5.31.1`

Release Notes

argoproj/argo-helm

`v5.31.1`

Compare Source

A Helm chart for Argo CD, a declarative, GitOps continuous delivery tool for Kubernetes.

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

View on GitHub

chore(deps): update helm release kubernetes-dashboard to v6.0.7 #40

renovate[bot] posted on May 05, 2023

This PR contains the following updates:

Package	Update	Change
kubernetes-dashboard	patch	`6.0.6` -> `6.0.7`

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

View on GitHub

chore(deps): update helm release nfs-subdir-external-provisioner to v4.0.18 #41

renovate[bot] posted on May 05, 2023

This PR contains the following updates:

Package	Update	Change
nfs-subdir-external-provisioner	patch	`4.0.2` -> `4.0.18`