onetaskgraph-linear 0.3.2

A onetaskgraph source over the Linear API.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

# The requests a Linear status write may send, counted at the loopback Linear's endpoint.
#
# Each budget's command is one journey of crates/onetaskgraph/tests/e2e/linear_budget.rs,
# run through scripts/linear-budget.sh against the loopback workspace — Hello Patient's
# vocabulary, configured with the per-kind `hellopatient` mapping — with no credential and
# no network. `bash scripts/check-linear-budgets.sh`, this crate's `budget-check` target,
# checks them all.
#
# The base each figure replaces is commit c9e75a8, measured through the same binary and
# engine calls on a configuration it completes (the shared workspace's team with no
# `status_mapping`, its projects at the dataset's own status names), and recorded in each
# budget's description, in the sentence beginning `Base (c9e75a8):`.
schema_version: 1
budgets:
  - id: linear-requests-per-status-write-cold
    description: >-
      Inner measure of headroom on a production Linear key every manager of a host shares,
      which no check may reach: the requests one status write sends on a fresh source
      instance, as one command line is — the highest of `task status set`, `task update
      --status` (each from a mapped state of one category to a mapped state of another), and
      `write_project`'s own requests for a project copy and for a routed member project, each
      with no tasks, labels or edges written by it, and both task verbs again through a source
      scoped to one project, to an issue of its project and to one filed in another project of
      its team. The resolution and the mutation.
      Base (c9e75a8): task status set 5 (ISSUE, ISSUE, TEAM, ISSUE_STATE_OF_TYPE,
      ISSUE_UPDATE); task update --status 5 (ISSUE, TEAM, ISSUE_STATE_OF_TYPE, ISSUE_UPDATE,
      ISSUE); write_project of a project copy 4 and of a routed member 4 (TEAM,
      PROJECT_STATUS, PROJECT_CREATE, PROJECT_RELATIONS); through a scoped source, to an issue
      of its project, task status set 5 and task update --status 5 (the same requests), and to
      one filed elsewhere neither completes — each is refused as no such task after 1 (ISSUE).
    labels: [linear]
    measure: reported
    command: ["bash", "../../scripts/linear-budget.sh", "linear-requests-per-status-write-cold"]
    unit: requests
    direction: max
    threshold: 2
    timeout_seconds: 1800
  - id: linear-requests-per-status-write-warm
    description: >-
      Inner measure of headroom on a production Linear key every manager of a host shares,
      which no check may reach: the requests each status write after the first sends on one
      source instance, as onepipeline's long-lived write-back worker holds one — the highest
      of a project copy's five task creates after its first write, five status-only
      `update_task` calls in one `Engine`, five more through a source scoped to one project,
      alternating between issues of its project and issues filed in another of its team, and
      five rewrites of one project a copy keeps in step, counting `write_project`'s own
      requests — every call in one `Engine` followed by `Engine::end_command`, as the worker
      ends each unit of work, which keeps the resolution. The mutation alone.
      Base (c9e75a8): a copy's task create 4 (TEAM, ISSUE_STATE, ISSUE_CREATE,
      ISSUE_RELATIONS); a status-only update 5 (ISSUE, TEAM, ISSUE_STATE_OF_TYPE,
      ISSUE_UPDATE, ISSUE), and through a scoped source 5 to an issue of its project (the same
      requests; the base held nothing between writes) while one filed elsewhere is refused as
      no such task after 1 (ISSUE); a project rewrite 4 (TEAM, PROJECT_STATUS, PROJECT_UPDATE,
      PROJECT_RELATIONS).
    labels: [linear]
    measure: reported
    command: ["bash", "../../scripts/linear-budget.sh", "linear-requests-per-status-write-warm"]
    unit: requests
    direction: max
    threshold: 1
    timeout_seconds: 1800
  - id: linear-requests-per-settlement-update-cold
    description: >-
      Inner measure of headroom on a production Linear key every manager of a host shares,
      which no check may reach: the requests the first settlement-shaped `update_task` — a
      status and one `onepipeline.*` metadata key — sends on a fresh source instance. The
      issue read the metadata slot is merged from, the resolution and the mutation; the
      person's text above the slot and every other key in it are held byte for byte.
      Base (c9e75a8): 5 (ISSUE, TEAM, ISSUE_STATE_OF_TYPE, ISSUE_UPDATE, ISSUE).
    labels: [linear]
    measure: reported
    command: ["bash", "../../scripts/linear-budget.sh", "linear-requests-per-settlement-update-cold"]
    unit: requests
    direction: max
    threshold: 3
    timeout_seconds: 1800
  - id: linear-requests-per-settlement-update-warm
    description: >-
      Inner measure of headroom on a production Linear key every manager of a host shares,
      which no check may reach: the requests each settlement-shaped `update_task` after the
      first sends on one source instance in one `Engine`, with `Engine::end_command` after
      each, as the write-back worker ends each settlement. The issue read and the mutation.
      Base (c9e75a8): 5 (ISSUE, TEAM, ISSUE_STATE_OF_TYPE, ISSUE_UPDATE, ISSUE).
    labels: [linear]
    measure: reported
    command: ["bash", "../../scripts/linear-budget.sh", "linear-requests-per-settlement-update-warm"]
    unit: requests
    direction: max
    threshold: 2
    timeout_seconds: 1800