Skip to content
Sign up

flagon-io/g1t

public
00

Where people and agents ship software together. The open-source git platform for the whole job: issues, agents, checks and deploys to the edge.

gitagentscloudflarerustforgemcp

Commit

Say work item where the runner, repos, deployments and kit said issue

G1T-Session:
ses_01m566357hejh9yeqjbetx23f3
syntaqxcommitted Parent63aa396Browse files
9 files+10−100/9 viewed
+2−2
235235 "metadata": { "workspaceId": "wsp_1" },
236236 "labels": { "goodFirstIssue": 3 },
237237 "byModel": { "claudeOpus": 1.5 },
238− "data": { "issueId": "iss_1", "outputs": { "artifactId": "a" } },
238+ "data": { "itemId": "iss_1", "outputs": { "artifactId": "a" } },
239239 }));
240240 assert_eq!(
241241 sent,
252252 "metadata": { "workspaceId": "wsp_1" },
253253 "labels": { "goodFirstIssue": 3 },
254254 "by_model": { "claudeOpus": 1.5 },
255− "data": { "issue_id": "iss_1", "outputs": { "artifactId": "a" } },
255+ "data": { "item_id": "iss_1", "outputs": { "artifactId": "a" } },
256256 })
257257 );
258258 assert!(camel_case_keys(&sent).is_empty());
+1−1
11 //! Runs commands against one commit and reports how each went: the merge
22 //! queue's runner of commands, and `MODE=checks`, which ran commands written
3−//! on issues before a pull request's checks were its workflows. g1t no
3+//! on work items before a pull request's checks were its workflows. g1t no
44 //! longer starts that mode; it stays for a sandbox already under way.
55 //!
66 //! The sandbox holds nothing but that commit, so a passing result says
+1−1
66 //! `mergecheck` finds out whether a pull request merges cleanly, `deploy`
77 //! builds a commit for g1t.page, `bump` makes a dependency update (one
88 //! package raised in its lockfiles, pushed as g1t), `backup` cuts a
9−//! repository's nightly backup bundle, and `checks` runs an issue's
9+//! repository's nightly backup bundle, and `checks` runs a work item's
1010 //! commands, from before checks were workflows. See the modules of those
1111 //! names. It talks to g1t only through the public API and git.
1212 //!
+1−1
1818 //! branch, commit}]`, the entry being tested last.
1919 //! - `CHECKS`: commands to run on the state, as a JSON array. g1t sends
2020 //! none now: the state is checked by its `merge_group` workflows.
21−//! - `CONTRACT_CHECKS`: the checks of issues already completed, which the
21+//! - `CONTRACT_CHECKS`: the checks of work items already completed, which the
2222 //! default branch has to keep passing. One that fails is run again on the
2323 //! base alone; if it fails there too, it was broken already and is not
2424 //! held against the stack.
+1−1
20792079 });
20802080 if (behind && attempts < RENAME_WAITS) throw new Error(`projects has not seen ${current} moved yet`);
20812081
2082− // Its history goes with it, as the repository's issues do.
2082+ // Its history goes with it, as its pull requests do.
20832083 const statements: D1PreparedStatement[] = [
20842084 this.db.prepare("UPDATE deployments SET repo = ? WHERE repo_id = ?").bind(current, move.repoId),
20852085 ];
+1−1
11 //! Pull requests' working copies after their pull request is done.
22 //!
3−//! Every pull request made from an issue works in its own copy of the
3+//! Every pull request made for a work item works in its own copy of the
44 //! repository in the git store (`pulls--<pull id>`, `fork_for_pull`).
55 //! Cloudflare does not say whether a fork shares objects with its source,
66 //! and storage is billed and capped per account (1 TB), so copies are not
+1−1
11 //! Forks people make into their workspaces: a fork network.
22 //!
33 //! A fork is an ordinary repository of the workspace it goes in, with its
4−//! own access, settings, rules, issues and pull requests, that remembers the
4+//! own access, settings, rules and pull requests, that remembers the
55 //! repository it came from (`parent_id`). That is all it shares: it can be
66 //! synced from its parent and can open pull requests into it. It is not a
77 //! pull request's working copy (`fork_of`, namespace `pulls`, forks.rs),
+1−1
11 //! `pushed`: what a push to a branch brought into it. Work asks after each
22 //! push, to mark merged the pull requests whose heads it brought in, as a
3−//! merge from the site would, and to close the issues its commits' messages
3+//! merge from the site would, and to land the work items its commits' messages
44 //! name after a closing keyword (work's pushed.rs).
55 //!
66 //! One walk from the new head, every parent followed, stopping at what the
+1−1
115115 }
116116
117117 /**
118− * What a sandbox is doing. Runs of an issue's commands (`checks`) are from
118+ * What a sandbox is doing. Runs of a work item's commands (`checks`) are from
119119 * before checks were workflows; a sandbox that was started for work g1t no
120120 * longer does is told apart by its kind and only cleaned up.
121121 */

Comments

Sign in to comment.