mirror of
https://github.com/svnscha/mcp-windbg.git
synced 2026-10-18 05:36:40 +08:00
Sven Scharmentke
cd15a7842a
Two changes. ## README: one heading per audience The install section interleaved three routes - a plugin block, a `pip install` block for "any other client", then a **Configure your client** step that circled back to Claude Code. A reader had to work out which lines applied to them. Now: ``` ## Quick start tip + prerequisites ## Install in Claude Code ### The plugin ### Registering the server yourself ## Install in another client ## Start debugging ``` Each path reads top to bottom without branching. **Python leaves the prerequisites list.** It is not one: the plugin fetches the server through `uvx`, and the native build will not need it either. Each route states its own requirement next to the command it applies to - "Needs uv" for the plugin, "Needs Python 3.10 or higher" for the two pip routes. **The enterprise policy tip moves to the top of Quick start.** It can change whether someone proceeds at all, so it belongs before the prerequisites rather than buried between install steps. I left the `Python 3.10+` badge in place - it is accurate metadata for the PyPI package, and removing it would lose real information for the pip routes. Say the word if you would rather it went too. ## ci.yml: push trigger drops main and master ```yaml branches: [ develop ] ``` - `master` does not exist (`git ls-remote --heads origin master` is empty). - `main` is moved solely by `fast-forward-main`, a `GITHUB_TOKEN` push, which by design starts no workflow. The run history confirms it: **zero** `push main` runs since the migration. Listing it implied a gate that cannot fire. `develop` stays, for two reasons that are easy to miss: 1. **The CI badge reads it** (`?branch=develop`). Remove the trigger and the badge falls back to whatever ran most recently anywhere - which is how it previously ended up showing "failing" off a blocked release-PR run. 2. **Merge skew.** PRs are squash-merged with no up-to-date-branch requirement, so a PR merged while behind `develop` produces a tree nobody tested. The push run is the only thing that exercises the merged result. ## Verified The VS Code JSON snippet parses (it briefly did not - a single-backslash `C:\Symbols` slipped in, the same defect this repo already shipped once in the plugin docs), the shell command keeps its single backslash, `ci.yml` parses with `push branches: [develop]`, and the docs formatter is clean.
25 lines
1.0 KiB
YAML
25 lines
1.0 KiB
YAML
name: CI
|
|
|
|
on:
|
|
pull_request:
|
|
push:
|
|
# develop only. master does not exist, and main is moved solely by
|
|
# fast-forward-main, a GITHUB_TOKEN push, which by design starts no
|
|
# workflow - so listing them implies a gate that cannot fire. The develop
|
|
# run is what the CI badge reads, and what catches a PR merged while behind.
|
|
branches: [ develop ]
|
|
workflow_dispatch:
|
|
|
|
jobs:
|
|
# Skip release PRs. They only carry version bumps and the CHANGELOG entry, and
|
|
# the full matrix runs again from publish-mcp.yml before anything ships, so the
|
|
# run here proves nothing. It also fails transiently: release-please pushes the
|
|
# version bump first and sync-lockfile updates uv.lock a moment later, so any
|
|
# CI in between sees a lockfile that does not match pyproject.toml and goes red
|
|
# on a state nobody will ever merge.
|
|
#
|
|
# head_ref is empty for push events, so those are unaffected.
|
|
build-and-test:
|
|
if: ${{ !startsWith(github.head_ref, 'release-please--') }}
|
|
uses: ./.github/workflows/build-and-test.yml
|