gardener: Upgrade Gardener to v0.1.15 and let mention-reply fix merge conflicts

[scuffi]

Gardener can now update open pull requests when a maintainer asks on them, including fixing merge conflicts. Conflicts are resolved with a merge commit, so the pull request's history is never rewritten.

What @gardener-cf can now do on a pull request

• Fix merge conflicts: "@gardener-cf please fix the conflicts" merges the pull request's base branch in. Gardener prepares the merge before the model runs; the model only resolves the conflicted files, runs the checks, and proposes a merge commit with both parents. Nothing is force-pushed.
• Touch up the pull request: "@gardener-cf rename this variable" pushes an ordinary commit onto the pull request's branch.
• Explain when it can't: pull requests that are closed or from a fork, conflicts in workflow, .gardener/ or CODEOWNERS files, and merges touching .gitattributes, .gitmodules, submodules or more than 1,000 files get an explanation instead of a change.

Safeguards

• Exact merge: every file outside the conflicted ones must be exactly Git's merge, so a merge commit can't hide other changes or drop the base branch's.
• No leftover markers: a conflicted file may not keep <<<<<<< or >>>>>>> lines.
• Protected files: workflow and Gardener files can only take the base branch's version.
• Fresh state at apply: apply refuses if the head moved, the base changed, or the base branch no longer contains the merged commit.
• Maintainers only: only maintainers can ask. It never pushes to the default branch or to forks.
• No CI on its pushes: like other workflow-token pushes, its commits don't start the pull request's checks, and the reply says so.

What changes in this repository

• mention-reply: checks out the pull request's head when the comment is on one, and gains the repository.merge_base tool and the commit.merge_base effect. commit.create and commit.merge_base may write to any branch except the default. The instructions now cover changing a pull request, merge conflicts, and when to rebase. Asked on a pull request for a separate pull request, it declines and suggests an issue, because its branch would carry the pull request's changes. Its bundle hash changes.
• Workflows: gardener-mention-reply.yml gains a pull_request input for manual runs and runs one round per pull request at a time. gardener-pr-review-fix.yml passes the pull request number instead of the head SHA, so a manual run given a pull request number now checks out its head and can run a review round; its instructions say so, which changes its bundle hash. triage and dependabot-merge are unchanged.
• Version pins: the workflows move to the 0.1.15 release, and gardener:generate points at @scuffi/gardener@0.1.15.
• Deployment: the runtime is already on 0.1.15.

Tested on a demo repository and on scuffi/gardener first

• Conflicts: a conflicted pull request was fixed from a comment with a merge commit, including one that also brought in a workflow change from the base branch exactly as the base had it.
• Touch-up: a test was added to a pull request from a comment.
• Refusals: a conflict inside a workflow file, a closed pull request, and a request to git rebase and force-push were each declined with an explanation.
• Manual run: a manual run against a pull request merged it.
• Separate pull request: asked on a pull request for a separate one, it declined and suggested an issue.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7258c6e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@cloudflare/computer@235

commit: 7258c6e

[devin-ai-integration]

Devin Review found 2 potential issues.

[devin-ai-integration]

🔴 Separate pull requests inherit existing changes

When a pull request comment asks for a separate PR, branch.create starts from that PR's head. The new-PR flow targets the default branch, so the separate PR includes the original changes.

Learn more

The task handles new code requests by creating a branch from the run's checkout and opening it against the default branch. For comments on a pull request, the new checkout is that pull request's head, even when the maintainer asks for a separate change rather than an update to that pull request. The resulting branch carries both sets of changes, and the new pull request shows them together.

Example: On a pull request that changes the filesystem API, a maintainer comments asking for a separate documentation PR. The new documentation PR also contains the filesystem API commits.

Recommended fix: Split the new-PR path from the existing-PR update path. For a separate PR requested in a pull request conversation, start from the default branch and build the change there rather than branching from the checked-out PR head; if the task cannot switch to a clean default-branch checkout, decline that route instead of opening a mixed PR.

---

Was this helpful? React with 👍 or 👎 to provide feedback.