Bump @balena/compose to 7.3.0 - #3041
Conversation
b1798ab to
57571c7
Compare
compose v7.0.12 removed ImageModel and ReleaseModel typings in favor of getting them from balena-sdk, so this bump necessitates changing some type sourcing from compose to SDK as well. Change-type: patch Signed-off-by: Christina Ying Wang <christina@balena.io>
Signed-off-by: Christina Ying Wang <christina@balena.io>
57571c7 to
97bf269
Compare
| type ServiceImage = Omit< | ||
| BalenaModel['image']['Read'], | ||
| 'created_at' | 'is_a_build_of__service' | ||
| >; |
There was a problem hiding this comment.
See Release.serviceImages below which omitted these two props from the image model. I'm unclear as to the reason but I assume the properties are set by the backend (computed properties?)
| type: string; | ||
| [key: string]: any; | ||
| }; | ||
|
|
There was a problem hiding this comment.
{ [key: string]: JSON } | JSON[] has never been the valid type for a contract from what I could find. Even the release contract field generated from balena.yml is the type as specified above. For example, tested on a device:
contract: {
description: "Test app for Intel NUC",
name: "NUCTest",
type: "sw.application",
version: "1.0.0",
data: {...}
}
Where is the { [key: string]: JSON } | JSON[] type being derived from?
| if ('is_a_build_of__service' in serviceImage) { | ||
| delete serviceImage.is_a_build_of__service; | ||
| // is_a_build_of__service is not an optional field in the SDK, but we need to delete it | ||
| serviceImage.is_a_build_of__service = undefined as any; |
There was a problem hiding this comment.
As mentioned above, these two fields are omitted in the ServiceImage type, unsure of reason but assuming that they're API-computed fields. However, this type error is due to balena-compose's releaseMod.create function returning the wrong type, so we should fix it there, then consider removing these deletes.
| serviceImage.dockerfile = props.dockerfile; | ||
| serviceImage.project_type = props.projectType; | ||
| serviceImage.dockerfile = props.dockerfile ?? null; | ||
| serviceImage.project_type = props.projectType ?? null; | ||
| if (props.startTime) { | ||
| serviceImage.start_timestamp = props.startTime; | ||
| serviceImage.start_timestamp = props.startTime.toISOString(); | ||
| } | ||
| if (props.endTime) { | ||
| serviceImage.end_timestamp = props.endTime; | ||
| serviceImage.end_timestamp = props.endTime.toISOString(); | ||
| } | ||
| serviceImage.push_timestamp = new Date(); | ||
| serviceImage.push_timestamp = new Date().toISOString(); |
There was a problem hiding this comment.
According to Balena Model in SDK, these timestamps are string format, and when querying a release using the SDK, they are returned in ISO time format. SBVR types categorizes date as any of the following:
import * as TypeUtils from '../type-utils';
export declare const types: {
postgres: string;
mysql: string;
websql: string;
odata: {
name: string;
};
};
export type Types = TypeUtils.TsTypes<string, string | number | Date>;
type DbWriteType = Date;
export declare const fetchProcessing: TypeUtils.FetchProcessing<Types['Read']>;
export declare const nativeFactTypes: TypeUtils.NativeFactTypes;
export declare const validate: TypeUtils.Validate<Types['Write'], DbWriteType>;
export {};
...so setting timestamps to ISO string should be ok for creating a service image, and if so, the toISOString conversion is just to align with the stricter SDK types. However, these timestamps were also okay before as raw JS Date objects. Correct or no?
| ); | ||
| if (skipLogUpload) { | ||
| delete serviceImage.build_log; | ||
| serviceImage.build_log = null; |
There was a problem hiding this comment.
build_log is non-optional but can be set to null
|
Waiting on #2997 |
1 participant
This bump adds support for
io.balena.requires.sw.linuxandio.balena.requires.sw.balena-oscontainer contract labels.compose v7.0.12 removed ImageModel and ReleaseModel typings in favor of getting them from balena-sdk, so this bump necessitates changing some type sourcing from compose to SDK as well.
Change-type: patch