@cesar-richard/git-connector-sdk 4.9.0 → 4.10.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/schema.d.ts +38 -18
- package/package.json +1 -1
package/dist/schema.d.ts
CHANGED
|
@@ -320,7 +320,7 @@ export interface components {
|
|
|
320
320
|
mergedBy: string | null;
|
|
321
321
|
/** @description Branch merged INTO. The source side is `branch`. */
|
|
322
322
|
targetBranch: string | null;
|
|
323
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
323
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
324
324
|
applications: string[];
|
|
325
325
|
number: string | number;
|
|
326
326
|
title: string;
|
|
@@ -427,7 +427,7 @@ export interface components {
|
|
|
427
427
|
mergedBy: string | null;
|
|
428
428
|
/** @description Branch merged INTO. The source side is `branch`. */
|
|
429
429
|
targetBranch: string | null;
|
|
430
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
430
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
431
431
|
applications: string[];
|
|
432
432
|
number: string | number;
|
|
433
433
|
title: string;
|
|
@@ -870,7 +870,7 @@ export interface components {
|
|
|
870
870
|
healthStatus: string | null;
|
|
871
871
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
872
872
|
severity: string | null;
|
|
873
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
873
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
874
874
|
applications: string[];
|
|
875
875
|
iteration: {
|
|
876
876
|
id: string | number;
|
|
@@ -1143,7 +1143,7 @@ export interface components {
|
|
|
1143
1143
|
healthStatus: string | null;
|
|
1144
1144
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
1145
1145
|
severity: string | null;
|
|
1146
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
1146
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
1147
1147
|
applications: string[];
|
|
1148
1148
|
iteration: {
|
|
1149
1149
|
id: string | number;
|
|
@@ -1174,6 +1174,10 @@ export interface components {
|
|
|
1174
1174
|
changedBy: string | null;
|
|
1175
1175
|
}[];
|
|
1176
1176
|
}[];
|
|
1177
|
+
/** @description Count of delivered issues matching the window/filters — NOT the page size. A CRA is an activity report: a page quietly presented as the whole answer removes deliveries from it with nothing on screen to say so (GH #72, 349 of 1175 real deliverables silently dropped). Compare against `issues.length` + `offset` to know whether more remains. In the rare case where the server's own internal candidate-loading ceiling was reached (an installation with more matching issues than that ceiling), `total` is a LOWER bound rather than exact — `truncated` is `true` in that case regardless of `limit`/`offset`, which is the signal to trust. */
|
|
1178
|
+
total: string | number;
|
|
1179
|
+
/** @description True when this page is not the whole window (`total > offset + issues.length`), OR when the server's internal candidate-loading ceiling was itself reached (see `total`) — in which case this is `true` even if the page looks complete by the slicing arithmetic alone. Raise `limit`/`offset` to see more. With `?application` set AND no `?limit` passed, candidate loading is already exhaustive (no SQL cap) before window filtering, so this is false and `total` is the exact count; passing `?limit` there opts back into normal paging and `truncated` is computed the same way as everywhere else. */
|
|
1180
|
+
truncated: boolean;
|
|
1177
1181
|
};
|
|
1178
1182
|
DeliveryReason: {
|
|
1179
1183
|
/** @description Discriminator: WHY the deliveryState was set. `rule_label_added` = a delivery label was added in the window; `closed_in_window` = fallback (no rule, issue closed in the window); `in_progress_opened_label_active` = a configured opened-label is currently active; `in_progress_delivered_after_window` = delivery label was added AFTER the window; `in_progress_fallback_open` = fallback (no rule, issue is open). */
|
|
@@ -2071,7 +2075,7 @@ export interface components {
|
|
|
2071
2075
|
healthStatus: string | null;
|
|
2072
2076
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
2073
2077
|
severity: string | null;
|
|
2074
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
2078
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
2075
2079
|
applications: string[];
|
|
2076
2080
|
iteration: {
|
|
2077
2081
|
id: string | number;
|
|
@@ -2308,7 +2312,7 @@ export interface components {
|
|
|
2308
2312
|
healthStatus: string | null;
|
|
2309
2313
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
2310
2314
|
severity: string | null;
|
|
2311
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
2315
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
2312
2316
|
applications: string[];
|
|
2313
2317
|
iteration: {
|
|
2314
2318
|
id: string | number;
|
|
@@ -2600,7 +2604,7 @@ export interface operations {
|
|
|
2600
2604
|
healthStatus: string | null;
|
|
2601
2605
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
2602
2606
|
severity: string | null;
|
|
2603
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
2607
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
2604
2608
|
applications: string[];
|
|
2605
2609
|
iteration: {
|
|
2606
2610
|
id: string | number;
|
|
@@ -2841,7 +2845,7 @@ export interface operations {
|
|
|
2841
2845
|
healthStatus: string | null;
|
|
2842
2846
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
2843
2847
|
severity: string | null;
|
|
2844
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
2848
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
2845
2849
|
applications: string[];
|
|
2846
2850
|
iteration: {
|
|
2847
2851
|
id: string | number;
|
|
@@ -3082,7 +3086,7 @@ export interface operations {
|
|
|
3082
3086
|
healthStatus: string | null;
|
|
3083
3087
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
3084
3088
|
severity: string | null;
|
|
3085
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
3089
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
3086
3090
|
applications: string[];
|
|
3087
3091
|
iteration: {
|
|
3088
3092
|
id: string | number;
|
|
@@ -3379,7 +3383,7 @@ export interface operations {
|
|
|
3379
3383
|
healthStatus: string | null;
|
|
3380
3384
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
3381
3385
|
severity: string | null;
|
|
3382
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
3386
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
3383
3387
|
applications: string[];
|
|
3384
3388
|
iteration: {
|
|
3385
3389
|
id: string | number;
|
|
@@ -3615,7 +3619,7 @@ export interface operations {
|
|
|
3615
3619
|
healthStatus: string | null;
|
|
3616
3620
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
3617
3621
|
severity: string | null;
|
|
3618
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
3622
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
3619
3623
|
applications: string[];
|
|
3620
3624
|
iteration: {
|
|
3621
3625
|
id: string | number;
|
|
@@ -3851,7 +3855,7 @@ export interface operations {
|
|
|
3851
3855
|
healthStatus: string | null;
|
|
3852
3856
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
3853
3857
|
severity: string | null;
|
|
3854
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
3858
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
3855
3859
|
applications: string[];
|
|
3856
3860
|
iteration: {
|
|
3857
3861
|
id: string | number;
|
|
@@ -4989,7 +4993,7 @@ export interface operations {
|
|
|
4989
4993
|
mergedBy: string | null;
|
|
4990
4994
|
/** @description Branch merged INTO. The source side is `branch`. */
|
|
4991
4995
|
targetBranch: string | null;
|
|
4992
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
4996
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
4993
4997
|
applications: string[];
|
|
4994
4998
|
number: string | number;
|
|
4995
4999
|
title: string;
|
|
@@ -5097,7 +5101,7 @@ export interface operations {
|
|
|
5097
5101
|
mergedBy: string | null;
|
|
5098
5102
|
/** @description Branch merged INTO. The source side is `branch`. */
|
|
5099
5103
|
targetBranch: string | null;
|
|
5100
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
5104
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
5101
5105
|
applications: string[];
|
|
5102
5106
|
number: string | number;
|
|
5103
5107
|
title: string;
|
|
@@ -5205,7 +5209,7 @@ export interface operations {
|
|
|
5205
5209
|
mergedBy: string | null;
|
|
5206
5210
|
/** @description Branch merged INTO. The source side is `branch`. */
|
|
5207
5211
|
targetBranch: string | null;
|
|
5208
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
5212
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
5209
5213
|
applications: string[];
|
|
5210
5214
|
number: string | number;
|
|
5211
5215
|
title: string;
|
|
@@ -5312,6 +5316,10 @@ export interface operations {
|
|
|
5312
5316
|
withIdentity?: string;
|
|
5313
5317
|
/** @description github | gitlab. */
|
|
5314
5318
|
source?: string;
|
|
5319
|
+
/** @description Max number of deliverables to return. Default 500, matching the historical (hardcoded) response size — raise it to see more of the window instead of guessing from a silently-capped list (GH #72). 0 is rejected (422): an empty page must never be read as 'nothing was delivered'. Paging does NOT reduce server work: `total` must describe the whole window, so every candidate in the window is loaded and run through `computeDeliverables` before the page is sliced. A consumer paging at limit=50 therefore pays one full window scan PER PAGE — prefer a single large limit. */
|
|
5320
|
+
limit?: string | number;
|
|
5321
|
+
/** @description Number of deliverables to skip, for paging past `limit`. Passing it alone (without `limit`) is enough to opt into pagination — the default limit of 500 then applies. This is a contract change from the historical behaviour: passing EITHER `limit` or `offset`, including `offset=0`, now opts into pagination, so a filtered call (e.g. `?application=x&offset=0`) that used to return its whole window exhaustively is now paged at the default limit. */
|
|
5322
|
+
offset?: string | number;
|
|
5315
5323
|
};
|
|
5316
5324
|
header?: never;
|
|
5317
5325
|
path?: never;
|
|
@@ -5566,7 +5574,7 @@ export interface operations {
|
|
|
5566
5574
|
healthStatus: string | null;
|
|
5567
5575
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
5568
5576
|
severity: string | null;
|
|
5569
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
5577
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
5570
5578
|
applications: string[];
|
|
5571
5579
|
iteration: {
|
|
5572
5580
|
id: string | number;
|
|
@@ -5597,6 +5605,10 @@ export interface operations {
|
|
|
5597
5605
|
changedBy: string | null;
|
|
5598
5606
|
}[];
|
|
5599
5607
|
}[];
|
|
5608
|
+
/** @description Count of delivered issues matching the window/filters — NOT the page size. A CRA is an activity report: a page quietly presented as the whole answer removes deliveries from it with nothing on screen to say so (GH #72, 349 of 1175 real deliverables silently dropped). Compare against `issues.length` + `offset` to know whether more remains. In the rare case where the server's own internal candidate-loading ceiling was reached (an installation with more matching issues than that ceiling), `total` is a LOWER bound rather than exact — `truncated` is `true` in that case regardless of `limit`/`offset`, which is the signal to trust. */
|
|
5609
|
+
total: string | number;
|
|
5610
|
+
/** @description True when this page is not the whole window (`total > offset + issues.length`), OR when the server's internal candidate-loading ceiling was itself reached (see `total`) — in which case this is `true` even if the page looks complete by the slicing arithmetic alone. Raise `limit`/`offset` to see more. With `?application` set AND no `?limit` passed, candidate loading is already exhaustive (no SQL cap) before window filtering, so this is false and `total` is the exact count; passing `?limit` there opts back into normal paging and `truncated` is computed the same way as everywhere else. */
|
|
5611
|
+
truncated: boolean;
|
|
5600
5612
|
};
|
|
5601
5613
|
"multipart/form-data": {
|
|
5602
5614
|
issues: {
|
|
@@ -5840,7 +5852,7 @@ export interface operations {
|
|
|
5840
5852
|
healthStatus: string | null;
|
|
5841
5853
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
5842
5854
|
severity: string | null;
|
|
5843
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
5855
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
5844
5856
|
applications: string[];
|
|
5845
5857
|
iteration: {
|
|
5846
5858
|
id: string | number;
|
|
@@ -5871,6 +5883,10 @@ export interface operations {
|
|
|
5871
5883
|
changedBy: string | null;
|
|
5872
5884
|
}[];
|
|
5873
5885
|
}[];
|
|
5886
|
+
/** @description Count of delivered issues matching the window/filters — NOT the page size. A CRA is an activity report: a page quietly presented as the whole answer removes deliveries from it with nothing on screen to say so (GH #72, 349 of 1175 real deliverables silently dropped). Compare against `issues.length` + `offset` to know whether more remains. In the rare case where the server's own internal candidate-loading ceiling was reached (an installation with more matching issues than that ceiling), `total` is a LOWER bound rather than exact — `truncated` is `true` in that case regardless of `limit`/`offset`, which is the signal to trust. */
|
|
5887
|
+
total: string | number;
|
|
5888
|
+
/** @description True when this page is not the whole window (`total > offset + issues.length`), OR when the server's internal candidate-loading ceiling was itself reached (see `total`) — in which case this is `true` even if the page looks complete by the slicing arithmetic alone. Raise `limit`/`offset` to see more. With `?application` set AND no `?limit` passed, candidate loading is already exhaustive (no SQL cap) before window filtering, so this is false and `total` is the exact count; passing `?limit` there opts back into normal paging and `truncated` is computed the same way as everywhere else. */
|
|
5889
|
+
truncated: boolean;
|
|
5874
5890
|
};
|
|
5875
5891
|
"text/plain": {
|
|
5876
5892
|
issues: {
|
|
@@ -6114,7 +6130,7 @@ export interface operations {
|
|
|
6114
6130
|
healthStatus: string | null;
|
|
6115
6131
|
/** @description Incident severity. Meaningful when `issueType === 'incident'`. */
|
|
6116
6132
|
severity: string | null;
|
|
6117
|
-
/** @description Slugs of the applications (see /v1/applications) that claim this item
|
|
6133
|
+
/** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
|
|
6118
6134
|
applications: string[];
|
|
6119
6135
|
iteration: {
|
|
6120
6136
|
id: string | number;
|
|
@@ -6145,6 +6161,10 @@ export interface operations {
|
|
|
6145
6161
|
changedBy: string | null;
|
|
6146
6162
|
}[];
|
|
6147
6163
|
}[];
|
|
6164
|
+
/** @description Count of delivered issues matching the window/filters — NOT the page size. A CRA is an activity report: a page quietly presented as the whole answer removes deliveries from it with nothing on screen to say so (GH #72, 349 of 1175 real deliverables silently dropped). Compare against `issues.length` + `offset` to know whether more remains. In the rare case where the server's own internal candidate-loading ceiling was reached (an installation with more matching issues than that ceiling), `total` is a LOWER bound rather than exact — `truncated` is `true` in that case regardless of `limit`/`offset`, which is the signal to trust. */
|
|
6165
|
+
total: string | number;
|
|
6166
|
+
/** @description True when this page is not the whole window (`total > offset + issues.length`), OR when the server's internal candidate-loading ceiling was itself reached (see `total`) — in which case this is `true` even if the page looks complete by the slicing arithmetic alone. Raise `limit`/`offset` to see more. With `?application` set AND no `?limit` passed, candidate loading is already exhaustive (no SQL cap) before window filtering, so this is false and `total` is the exact count; passing `?limit` there opts back into normal paging and `truncated` is computed the same way as everywhere else. */
|
|
6167
|
+
truncated: boolean;
|
|
6148
6168
|
};
|
|
6149
6169
|
};
|
|
6150
6170
|
};
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@cesar-richard/git-connector-sdk",
|
|
3
|
-
"version": "4.
|
|
3
|
+
"version": "4.10.0",
|
|
4
4
|
"description": "TypeScript SDK for the git-connector v1 API (work items + iterations aggregated from GitHub/GitLab). Version published on npm tracks server releases.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"repository": {
|