Instead of using the more generic resin-discoverable-services lib which is unmantained
and currently has several vulnerabilities and forks for fixing issues (that were later on fixed upstream)
we directly talk with mDNS using standard (and currently mantained) bonjour-service.
Change-type: patch
When constructing the target state after a reported change from livepush, the
handler function would not pass all build tasks to the function that
constructs the target state, causing a TypeError when trying to obtain
the target image name for each service. This updates the handler to pass
all build tasks, ensuring the information is available to construct the
target state.
Relates-to: #2724
Change-type: patch
Update balena-sdk from 17.21.1 to 18.0.0
Update balena-preload from 14.0.0 to 14.0.2
Update balena-image-manager from 9.0.0 to 9.0.2
Change-type: patch
This allows the the CLI to use docker registry config when querying the
images manifest.
Relates-to: balena-io-modules/balena-compose#31
Change-type: patch
Allow to generate a config file with `installer.secureboot` set so that
a secure boot and disk encrypted system can be installed.
Change-type: minor
Signed-off-by: Alex Gonzalez <alexg@balena.io>
On local push, the CLI uses `localrelease` as the `commit` property for
the development application. This is not a valid uuid and will not be
read properly by the supervisor, as seen in
https://github.com/balena-os/balena-supervisor/blob/master/src/compose/service.ts#L652
While this is not a problem right now, the commit is becoming the main
way to identify a service release (replacing `releaseId` and `imageId`),
and the invalid release uuid could cause update issues when pushing a
local release on when using some API endpoints.
Change-type: patch
Relates-to: balena-os/balena-supervisor#2136
If the cli has not been run in a while, it will show old update information. It's not obvious why, and this might lead to confusion. So this commit just adds a comment to clarify that out-of-date update notifier info is expected behaviour, and why.
When using livepush, the CLI parses the build logs to obtain the stage
image ids, which are necessary for properly running livepush.
This process used to store the full log output in memory before parsing
the logs for obtaining the stage ids. We have seen this cause issues
before because of the excessive memory usage and it is one the suspects
of #2165, which is blocking the update to Node 14
Change-type: patch