From 603e6020def84526e73e81d7e8549d41aa643fba Mon Sep 17 00:00:00 2001 From: Martin Vogel Date: Sun, 26 Jul 2026 02:56:17 +0200 Subject: [PATCH 1/2] feat(ci): acknowledge new pull requests automatically Contributors could not distinguish "blocked" from "ignored". Several PRs sat on green, mergeable work for over a week with no maintainer comment while release-critical work absorbed review capacity, and nothing on the PR page said so. GitHub has no repo-scoped banner for pull requests -- an org announcement banner renders only for org members, and pinned issues and discussions never appear on the PR tab -- so a comment on open is the only surface that reaches an external contributor at the moment they contribute. Posts one comment when a PR is opened, stating that it is queued, that it will not be closed for inactivity, and what genuinely speeds up review (rebased branch, green CI, one claim per PR, signed-off commits). The message lives in .github/pr-acknowledgement.md rather than in the workflow, so the status can be edited -- or acknowledgements switched off by blanking the file -- without a workflow change. A missing, empty, or whitespace-only file is the documented off switch. Uses pull_request_target because a pull_request trigger hands fork PRs a read-only token, which would fail on exactly the contributions most worth acknowledging. The job never checks out, builds, or executes PR code: checkout carries no ref and so resolves to the base commit, it is used only to read our own message file, and the PR number reaches the shell through the environment rather than string interpolation. Skips bots and owner-authored PRs. Signed-off-by: Martin Vogel --- .github/pr-acknowledgement.md | 34 ++++++++++++ .github/workflows/pr-acknowledgement.yml | 67 ++++++++++++++++++++++++ 2 files changed, 101 insertions(+) create mode 100644 .github/pr-acknowledgement.md create mode 100644 .github/workflows/pr-acknowledgement.yml diff --git a/.github/pr-acknowledgement.md b/.github/pr-acknowledgement.md new file mode 100644 index 000000000..3c5f60644 --- /dev/null +++ b/.github/pr-acknowledgement.md @@ -0,0 +1,34 @@ + + +Thanks for opening this — it has been seen, and it is queued. + +This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. + +**Current review status: reviews are running behind.** We are finishing release-critical work for `0.9.1-rc.1` — a coordination daemon that changed how the whole system runs, and the root-cause fix for a severe Windows memory leak ([#581](https://github.com/DeusData/codebase-memory-mcp/issues/581)) that could exhaust a machine's commit charge over hours. Those changes cross the memory allocator, thread lifecycle, and the store-resolution path that every tool call runs through, so merging other work on top of them while they settle would leave neither change trustworthy. The full explanation is in [discussion #1144](https://github.com/DeusData/codebase-memory-mcp/discussions/1144). + +What that means for this PR, concretely: + +- **It will not be closed for inactivity.** No stale bot touches pull requests here. +- It may sit longer than it should before a human reads it. That is on us, not on you. +- Review resumes once the release path is clear. + +Things that will genuinely speed it up whenever review does happen: + +- **Keep it rebased** on `main` — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended. +- **Get CI green**, or say which failures you believe are pre-existing. +- **Keep the change to one claim.** Bundled features and refactors get split before they get merged, which costs you a round trip. +- Every commit needs a sign-off (`git commit -s`) — CI enforces DCO. + +If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. + +Thanks for contributing, and sorry in advance for the wait. diff --git a/.github/workflows/pr-acknowledgement.yml b/.github/workflows/pr-acknowledgement.yml new file mode 100644 index 000000000..7c8d47df4 --- /dev/null +++ b/.github/workflows/pr-acknowledgement.yml @@ -0,0 +1,67 @@ +name: PR acknowledgement + +# Posts one acknowledgement comment when a pull request is opened, so a +# contributor learns the current review status immediately instead of inferring +# it from silence. +# +# The message text lives in `.github/pr-acknowledgement.md`. Edit that file to +# change what is said; blank it (or delete it) to turn acknowledgements off +# without touching this workflow. No code change is needed to switch it. +# +# SECURITY — this uses `pull_request_target`, which runs against the BASE repo +# with a token that can write. That is required: a `pull_request` trigger gives +# fork PRs a read-only token, so commenting on exactly the contributions we most +# want to acknowledge would fail. +# +# The safety rule that makes it sound: this job NEVER checks out, builds, or +# executes pull-request code. `actions/checkout` here resolves to the base +# commit (the default under `pull_request_target`), and it is used only to read +# the message file out of our own tree. Do not add a `ref:` pointing at the PR +# head, and do not add a build step. Nothing from the PR is interpolated into a +# shell command either — the body comes from a file, and the PR number is passed +# through the environment rather than expanded inline. + +on: + pull_request_target: + types: [opened] + +permissions: + contents: read + +jobs: + acknowledge: + runs-on: ubuntu-latest + # Bots do not read comments, and acknowledging our own PRs is noise. + if: >- + github.event.pull_request.user.type != 'Bot' && + github.event.pull_request.author_association != 'OWNER' + permissions: + pull-requests: write + steps: + - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 + with: + # Base commit only — never the PR head. See the security note above. + persist-credentials: false + + - name: Post acknowledgement + env: + GH_TOKEN: ${{ github.token }} + PR_NUMBER: ${{ github.event.pull_request.number }} + REPO: ${{ github.repository }} + run: | + set -euo pipefail + MESSAGE_FILE=.github/pr-acknowledgement.md + + if [ ! -f "$MESSAGE_FILE" ]; then + echo "No $MESSAGE_FILE in the base tree — acknowledgements are off." + exit 0 + fi + + # An empty or whitespace-only file is the documented off switch. + if [ -z "$(tr -d '[:space:]' < "$MESSAGE_FILE")" ]; then + echo "$MESSAGE_FILE is blank — acknowledgements are off." + exit 0 + fi + + gh pr comment "$PR_NUMBER" --repo "$REPO" --body-file "$MESSAGE_FILE" + echo "Acknowledged PR #${PR_NUMBER}." From 05dc3fc4979d6b3c66b4d2902df98585982b31d9 Mon Sep 17 00:00:00 2001 From: Martin Vogel Date: Fri, 31 Jul 2026 02:29:13 +0200 Subject: [PATCH 2/2] docs(ci): tell contributors the release freeze is over, not that it is ongoing The acknowledgement text described a state of the world that ended when 0.9.1-rc.1 published: it told every new contributor we were still finishing release-critical work and that "review resumes once the release path is clear". Posting that now would be false on the day it starts running. This is the obligation the PR description already set for itself -- the review-status section is a public promise and has to be edited when the situation it describes changes. Doing that before the workflow ever posts, rather than after someone reads a stale freeze notice, is the point. The queue is still real, so the section stays rather than being removed: the freeze is over, a large backlog is not, and PRs are being read oldest-first. Saying that is more useful to someone opening a PR today than either the old text or silence, because it explains why a recent PR sits behind older ones. Signed-off-by: Martin Vogel --- .github/pr-acknowledgement.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/pr-acknowledgement.md b/.github/pr-acknowledgement.md index 3c5f60644..9e5ac17e2 100644 --- a/.github/pr-acknowledgement.md +++ b/.github/pr-acknowledgement.md @@ -14,13 +14,13 @@ Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. -**Current review status: reviews are running behind.** We are finishing release-critical work for `0.9.1-rc.1` — a coordination daemon that changed how the whole system runs, and the root-cause fix for a severe Windows memory leak ([#581](https://github.com/DeusData/codebase-memory-mcp/issues/581)) that could exhaust a machine's commit charge over hours. Those changes cross the memory allocator, thread lifecycle, and the store-resolution path that every tool call runs through, so merging other work on top of them while they settle would leave neither change trustworthy. The full explanation is in [discussion #1144](https://github.com/DeusData/codebase-memory-mcp/discussions/1144). +**Current review status: working through a backlog.** `0.9.1-rc.1` is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in [discussion #1144](https://github.com/DeusData/codebase-memory-mcp/discussions/1144). What that means for this PR, concretely: - **It will not be closed for inactivity.** No stale bot touches pull requests here. -- It may sit longer than it should before a human reads it. That is on us, not on you. -- Review resumes once the release path is clear. +- It may still sit a while before a human reads it. That is on us, not on you. +- Older PRs are read first, so a recent one is not being skipped — it is behind a queue. Things that will genuinely speed it up whenever review does happen: