syntaqxA pull request's page no longer waits for its merge options. The loader awaited work's merge_choices beside everything else, and that call reads the branch's commits for the default merge messages (repos inspect_commits fetches and reads a pack from the git store every time) and asked repos whether it is behind: 6 to 10 seconds for flagon-io/g1t #39 and #41 (Server-Timing: work 9 calls, 7.5 s inside, 214 ms of it the database), long enough for the page to time out. Now the merge box opens on what the repository's settings allow, as it did when the service could not answer, and takes the service's choices, with their messages, in place when they stream in (useArrived), keeping the method picked and a dialog that is open. Merge options are asked for only for an open or draft pull request; a merged or closed one never needed them. In work, merge_choices takes whether it is behind from what was stored with its mergeability for its head as it is now, as get_pull does (behind_now, else repos), beside its settings rather than after them. Checked: cargo test for g1t-work (189), the site's typecheck and unit tests (934).e446ed4History
README.md
g1t/workflows
g1t's own reusable workflows, published from this folder of g1t's
repository to g1t/workflows on g1t.sh by .g1t/workflows/actions-release.yml.
| Workflow | What it does |
|---|---|
.g1t/workflows/deploy.yml | Builds the commit onto g1t.page with g1t/deploy. The deploy workflow g1t manages for a project calls it. |
jobs:
g1t:
uses: g1t/workflows/.g1t/workflows/deploy.yml@v1
with:
project: web
secrets: inherityaml