mirror of
https://github.com/multica-ai/multica.git
synced 2026-09-29 16:59:28 +08:00
Bohan Jiangandmultica-agent
9018df3efb
* feat(projects): set a repository's checkout ref from the UI (MUL-7504) A project that tracks one delivery line could already pin the branch its tasks start from — `github_repo.resource_ref.ref` has been stored, sent to the daemon and honored at checkout since #4467. The UI only ever displayed it. Anyone working through the web, desktop or mobile app had to drop to `multica project resource update --ref` to set something the interface already showed as a property of the resource, and until they did, every task silently started from the remote default branch. This adds the missing input, on the three paths a repository is configured: - Create-project modal: a "Branch, tag, or commit" field per selected repo, shown once a URL is entered so the common default-branch case still reads as one field. - Resource panel: the same field in the attach form, plus a dialog on each attached repo — the row previously offered only delete. - Mobile: the field in the attach sheet, and the ref rendered in the list, which never showed it at all. Three details the shape of the existing code forced: - The ref renders on its own line rather than appended to the repo label. A custom name took that slot, so naming a repo hid the one signal that its tasks do not start from the default branch — and mobile is the only client that collects a name. - Edits spread the stored ref before overwriting. The server replaces resource_ref wholesale, so a payload carrying only `ref` is rejected for a missing URL. - Pasting a `.../tree/<branch>` URL now splits into the two fields. Mobile's URL check accepted that whole string and stored it as the clone URL, so the gap was already producing targets that cannot be cloned. Server-side, `ref` was stored with no validation beyond a trim, so a typo survived to checkout and surfaced as a daemon 500 naming its local repo cache, minutes later and to whoever ran the task rather than whoever typed it. validateGitRef applies the shape rules from `git check-ref-format` plus a length cap. Existence on the remote is deliberately still not checked: the server cannot see the repository, and an offline daemon or a private repo must not block saving configuration. Free text rather than a branch picker, by design. Nothing in the product can list a repository's branches today, and a picker could not express a tag or a commit SHA anyway. A "list remote branches" endpoint remains the follow-up #8572 proposes; it should stay an input aid, never the only way. Co-authored-by: multica-agent <github@multica.ai> * feat(projects): make the pinned branch the delivery target too (MUL-7504) Pinning a repository's starting point only solved half the problem. Nothing in Multica creates pull requests — `gh pr create` is the agent's own call, and without `--base` it targets the repository's default branch. So a project pinned to `release/2026-09` had its agents start in the right place and then open pull requests into `main`, carrying every commit the release line had that `main` lacked. Product review asked for the two halves to move together, so the brief now states both. The Repositories section names each repo's starting point and, when anything is pinned, says to deliver back to it. The Project Context bullet stops implying `--ref` is how you reach the configured revision — the daemon already applied it, and `--ref` is the override. The delivery rule is stated conditionally, because a pin is not necessarily a branch. The field accepts anything git resolves, and neither the server nor the daemon can tell a branch from a tag or a commit without asking the remote — which the product deliberately does not do. A tag has nothing to merge back into, so the agent is told to confirm rather than guess a base. That same ambiguity shapes how the UI narrows to branches. The field now says "Starting branch" and explains that tasks both start and deliver there, but the promise cannot be enforced: `v1.2.3` is a legal branch name and `main` is a legal tag. Only a full-length object id is unambiguous, and only that is declined, pointing at `multica repo checkout --ref` where a one-off revision belongs. The stored grammar is unchanged, so the CLI and API still accept tags and commits — the daemon has always resolved all three, and this is a UI-level product choice, not a data restriction. Two fixes from the same review: - An unpinned repository now reads "Default branch" instead of showing nothing. Clearing a branch used to make the line vanish, which looks identical to the setting never having existed — there was no way to confirm from the panel that a repo was deliberately on its default, or that the row had a branch setting at all. - The edit dialog says the change applies to newly started work. The ref is read when a task is claimed, so work already underway keeps the branch it started on, and the copy now says so rather than leaving it to be discovered. Co-authored-by: multica-agent <github@multica.ai> * fix(projects): close three gaps in the starting-branch flow (MUL-7504) All three found in review of the two commits before this one. **A resumed task could be told to deliver somewhere new.** The starting point in the brief is the project's CURRENT setting, read when the run was claimed. A task that started from `release/a`, left uncommitted work and resumed after the project moved to `release/b` kept its old checkout — the work is still branched off `release/a` — while the brief now named `release/b` and told it to deliver there. Following that would push the old line's work into the new one, and would break what the edit dialog promises: work already underway keeps the branch it started on. The brief cannot settle this alone, because whether a checkout gets reused is only known once `repo checkout` runs. It defers to the checkout instead, which already reports `Kept` and names the branch it is on. **Create Project accepted a branch it had already rejected.** The submit gate only checked the add-a-repo field, so a branch edited on an already-selected repo reached the payload with nothing but an inline error to show for it — and the server accepts commit ids by design, so nothing downstream caught it. Both the button and handleSubmit now check every selected repo; the button alone was never enough, since TitleEditor's onSubmit calls handleSubmit directly. **A second pasted browse URL was stored whole.** Splitting `/tree/<branch>` was gated on the branch field being empty, so pasting another repository's browse URL after one was already filled in saved the entire `/tree/...` string as the clone URL — a target that cannot be cloned. Normalising the URL is now unconditional in all three entry points. Whether to overwrite the BRANCH is the separate question, and the pasted pair wins: the branch field only appears once a URL is present, so a value sitting in it came from the previous URL rather than from something typed ahead of time. One defect the review surfaced indirectly: GithubRefField took an optional `id` and the per-repo instance in the create-project modal passed none, which detached the label from its input — leaving the field unnamed for a screen reader, and unreachable by getByLabelText, which is why the gap had no test. The id is now generated when omitted. Co-authored-by: multica-agent <github@multica.ai> * fix(execenv): stop naming the checkout as the resumed delivery target (MUL-7504) The resume warning added in the previous commit told the agent to deliver kept work "to the branch it actually started from, which the checkout names". The second clause is wrong. A kept checkout reports the branch the worktree is ON — resolved by `git symbolic-ref`, so the task's own `agent/<name>/<task>` branch. That is the HEAD of a pull request, never its base, and nothing in WorktreeResult carries the ref it was cut from. An agent following that sentence would pass its own branch as `--base` and open a pull request whose base equals its head. The warning now says what the reported branch actually is, and points at the sources that do settle the question: the base of the work's existing pull request, or the target the task states, and ask when neither does. It also moves out of the `if pinned` branch. A project cleared back to its default branch renders no starting point at all, yet a task resumed after that change still holds a checkout cut from the old one — gating the warning on a pin dropped it exactly where the mismatch is invisible. The one sentence that only makes sense alongside a listed starting point ("do not retarget it to a starting point listed above") stays conditional, so the cleared variant does not point at a line that is not there. Regressions cover both resume shapes — pinned A to B, and A cleared to the default branch — plus the specific wrong phrasing, so it cannot come back. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>
63 lines
3.3 KiB
TypeScript
63 lines
3.3 KiB
TypeScript
import { test, expect } from "@playwright/test";
|
|
import { loginAsDefault, waitForPageText } from "./helpers";
|
|
|
|
const REPO = "https://github.com/multica-ai/multica";
|
|
|
|
/**
|
|
* The checkout ref of a github_repo project resource, end to end.
|
|
*
|
|
* Covers what only the full stack can show: the ref survives project creation,
|
|
* comes back on the project page, and an edit persists — the server replaces
|
|
* resource_ref wholesale rather than deep-merging, so a payload that drops the
|
|
* URL is a class of bug the component tests alone cannot see.
|
|
*/
|
|
test("pins, edits and clears a repository's checkout ref", async ({ page }) => {
|
|
const slug = await loginAsDefault(page);
|
|
|
|
await page.goto(`/${slug}/projects`, { waitUntil: "domcontentloaded" });
|
|
await waitForPageText(page, "Projects");
|
|
await page.getByRole("button", { name: /new project/i }).first().click();
|
|
|
|
// TitleEditor is a contenteditable, not an <input> with a placeholder attr.
|
|
await page.getByRole("textbox", { name: /project title/i }).fill("Release line");
|
|
await page.getByRole("button", { name: /repos/i }).first().click();
|
|
await page.getByPlaceholder(/github\.com\/owner\/repo/i).fill(REPO);
|
|
await page.getByLabel(/starting branch/i).fill("release/2026-09");
|
|
await page.getByRole("button", { name: /^add$/i }).click();
|
|
await page.getByRole("button", { name: /^create project$/i }).click();
|
|
|
|
await waitForPageText(page, "Release line");
|
|
await expect(page.getByText("release/2026-09")).toBeVisible({ timeout: 15000 });
|
|
|
|
// Editing an attached resource — the affordance the UI never had.
|
|
await page.getByTitle(/change the branch tasks work on/i).first().click();
|
|
await expect(page.getByText(/which branch should tasks work on/i)).toBeVisible();
|
|
|
|
// A ref git could not resolve is refused before it is stored, rather than
|
|
// failing minutes later inside a task with a repo-cache error.
|
|
await page.getByLabel(/starting branch/i).fill("main..dev");
|
|
await expect(page.getByRole("button", { name: /^save$/i })).toBeDisabled();
|
|
|
|
await page.getByLabel(/starting branch/i).fill("v1.4.0");
|
|
await page.getByRole("button", { name: /^save$/i }).click();
|
|
await expect(page.getByText("v1.4.0")).toBeVisible({ timeout: 10000 });
|
|
await expect(page.getByText("release/2026-09")).toHaveCount(0);
|
|
|
|
// The saved value survives a reload — i.e. it reached the database, and the
|
|
// URL rode along with it rather than being replaced away.
|
|
await page.reload({ waitUntil: "domcontentloaded" });
|
|
await expect(page.getByText("v1.4.0")).toBeVisible({ timeout: 15000 });
|
|
await expect(page.getByText("multica-ai/multica")).toBeVisible();
|
|
|
|
// Clearing goes back to the repository's default branch.
|
|
await page.getByTitle(/change the branch tasks work on/i).first().click();
|
|
await page.getByLabel(/starting branch/i).fill("");
|
|
await page.getByRole("button", { name: /^save$/i }).click();
|
|
await expect(page.getByText("v1.4.0")).toHaveCount(0, { timeout: 10000 });
|
|
await expect(page.getByText("multica-ai/multica")).toBeVisible();
|
|
// Not an empty row: an unpinned repo says which branch it uses, so clearing
|
|
// is confirmable rather than indistinguishable from the setting not existing.
|
|
// Exact text, because the success toast also says "Back to the default branch".
|
|
await expect(page.getByText("Default branch", { exact: true })).toBeVisible();
|
|
});
|