@cesar-richard/git-connector-sdk 4.20.2 → 4.20.4
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 +8 -8
- package/package.json +1 -1
package/dist/schema.d.ts
CHANGED
|
@@ -2212,7 +2212,7 @@ export interface components {
|
|
|
2212
2212
|
stage: string | null;
|
|
2213
2213
|
/** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
|
|
2214
2214
|
origin: "closed" | "status" | "label" | "signals";
|
|
2215
|
-
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin,
|
|
2215
|
+
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin: for `origin: 'signals'` it is always `null`; for `origin: 'status'` it is the date of the LAST entry of the native-status chronology (`_gc.statusChanges`, GitLab system notes), and only when that entry carries the current status — `null` when the tracker declares no delivering status (the chronology is then never fetched), when the issue predates history tracking, or when the chronology ends on another name (a renamed status, GitLab freezing the old name into the note); for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
|
|
2216
2216
|
stateSince: string | null;
|
|
2217
2217
|
};
|
|
2218
2218
|
iteration: {
|
|
@@ -2467,7 +2467,7 @@ export interface components {
|
|
|
2467
2467
|
stage: string | null;
|
|
2468
2468
|
/** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
|
|
2469
2469
|
origin: "closed" | "status" | "label" | "signals";
|
|
2470
|
-
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin,
|
|
2470
|
+
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin: for `origin: 'signals'` it is always `null`; for `origin: 'status'` it is the date of the LAST entry of the native-status chronology (`_gc.statusChanges`, GitLab system notes), and only when that entry carries the current status — `null` when the tracker declares no delivering status (the chronology is then never fetched), when the issue predates history tracking, or when the chronology ends on another name (a renamed status, GitLab freezing the old name into the note); for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
|
|
2471
2471
|
stateSince: string | null;
|
|
2472
2472
|
};
|
|
2473
2473
|
iteration: {
|
|
@@ -2849,7 +2849,7 @@ export interface operations {
|
|
|
2849
2849
|
stage: string | null;
|
|
2850
2850
|
/** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
|
|
2851
2851
|
origin: "closed" | "status" | "label" | "signals";
|
|
2852
|
-
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin,
|
|
2852
|
+
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin: for `origin: 'signals'` it is always `null`; for `origin: 'status'` it is the date of the LAST entry of the native-status chronology (`_gc.statusChanges`, GitLab system notes), and only when that entry carries the current status — `null` when the tracker declares no delivering status (the chronology is then never fetched), when the issue predates history tracking, or when the chronology ends on another name (a renamed status, GitLab freezing the old name into the note); for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
|
|
2853
2853
|
stateSince: string | null;
|
|
2854
2854
|
};
|
|
2855
2855
|
iteration: {
|
|
@@ -3108,7 +3108,7 @@ export interface operations {
|
|
|
3108
3108
|
stage: string | null;
|
|
3109
3109
|
/** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
|
|
3110
3110
|
origin: "closed" | "status" | "label" | "signals";
|
|
3111
|
-
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin,
|
|
3111
|
+
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin: for `origin: 'signals'` it is always `null`; for `origin: 'status'` it is the date of the LAST entry of the native-status chronology (`_gc.statusChanges`, GitLab system notes), and only when that entry carries the current status — `null` when the tracker declares no delivering status (the chronology is then never fetched), when the issue predates history tracking, or when the chronology ends on another name (a renamed status, GitLab freezing the old name into the note); for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
|
|
3112
3112
|
stateSince: string | null;
|
|
3113
3113
|
};
|
|
3114
3114
|
iteration: {
|
|
@@ -3367,7 +3367,7 @@ export interface operations {
|
|
|
3367
3367
|
stage: string | null;
|
|
3368
3368
|
/** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
|
|
3369
3369
|
origin: "closed" | "status" | "label" | "signals";
|
|
3370
|
-
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin,
|
|
3370
|
+
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin: for `origin: 'signals'` it is always `null`; for `origin: 'status'` it is the date of the LAST entry of the native-status chronology (`_gc.statusChanges`, GitLab system notes), and only when that entry carries the current status — `null` when the tracker declares no delivering status (the chronology is then never fetched), when the issue predates history tracking, or when the chronology ends on another name (a renamed status, GitLab freezing the old name into the note); for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
|
|
3371
3371
|
stateSince: string | null;
|
|
3372
3372
|
};
|
|
3373
3373
|
iteration: {
|
|
@@ -3682,7 +3682,7 @@ export interface operations {
|
|
|
3682
3682
|
stage: string | null;
|
|
3683
3683
|
/** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
|
|
3684
3684
|
origin: "closed" | "status" | "label" | "signals";
|
|
3685
|
-
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin,
|
|
3685
|
+
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin: for `origin: 'signals'` it is always `null`; for `origin: 'status'` it is the date of the LAST entry of the native-status chronology (`_gc.statusChanges`, GitLab system notes), and only when that entry carries the current status — `null` when the tracker declares no delivering status (the chronology is then never fetched), when the issue predates history tracking, or when the chronology ends on another name (a renamed status, GitLab freezing the old name into the note); for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
|
|
3686
3686
|
stateSince: string | null;
|
|
3687
3687
|
};
|
|
3688
3688
|
iteration: {
|
|
@@ -3936,7 +3936,7 @@ export interface operations {
|
|
|
3936
3936
|
stage: string | null;
|
|
3937
3937
|
/** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
|
|
3938
3938
|
origin: "closed" | "status" | "label" | "signals";
|
|
3939
|
-
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin,
|
|
3939
|
+
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin: for `origin: 'signals'` it is always `null`; for `origin: 'status'` it is the date of the LAST entry of the native-status chronology (`_gc.statusChanges`, GitLab system notes), and only when that entry carries the current status — `null` when the tracker declares no delivering status (the chronology is then never fetched), when the issue predates history tracking, or when the chronology ends on another name (a renamed status, GitLab freezing the old name into the note); for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
|
|
3940
3940
|
stateSince: string | null;
|
|
3941
3941
|
};
|
|
3942
3942
|
iteration: {
|
|
@@ -4190,7 +4190,7 @@ export interface operations {
|
|
|
4190
4190
|
stage: string | null;
|
|
4191
4191
|
/** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
|
|
4192
4192
|
origin: "closed" | "status" | "label" | "signals";
|
|
4193
|
-
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin,
|
|
4193
|
+
/** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin: for `origin: 'signals'` it is always `null`; for `origin: 'status'` it is the date of the LAST entry of the native-status chronology (`_gc.statusChanges`, GitLab system notes), and only when that entry carries the current status — `null` when the tracker declares no delivering status (the chronology is then never fetched), when the issue predates history tracking, or when the chronology ends on another name (a renamed status, GitLab freezing the old name into the note); for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
|
|
4194
4194
|
stateSince: string | null;
|
|
4195
4195
|
};
|
|
4196
4196
|
iteration: {
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@cesar-richard/git-connector-sdk",
|
|
3
|
-
"version": "4.20.
|
|
3
|
+
"version": "4.20.4",
|
|
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": {
|