This is to prevent the target state cache from getting written to host
during tests.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
Alpine allows the `~=` syntax to match a part of the package version
when installing. In this case we want to use it to specify node and
npm major versions
Change-type: patch
Memory tests have shown performance improvements to using the native method.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
Update balena-io/deploy-to-balena-action
Changelog-entry: Update balena-io/deploy-to-balena-action to v1.0.3
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
We were still on 3.16, where the nodejs package was
pointed at Node 16. 3.18 moves the pointer to Node 18.
Change-type: minor
Signed-off-by: Christina Ying Wang <christina@balena.io>
This change is mainly for the hostOS
to know if update locks should be ignored
when updating to a newer version.
Change-type: patch
Signed-off-by: jaomaloy <jao.maloy@balena.io>
The node-dbus module is unmaintained and a blocker for the update to
Node 18. Switching to our own node bindings for systemd solves this
issue
Relates-to: Shouqun/node-dbus#241
Change-type: patch
This is being done to keep the source of truth for this variable in one place and reduce confusion since it's better for dashboard users to reference the dashboard option rather than the actual variable name
We need the supervisor to be able to manage config.txt changes for the
Revolution Pi Connect S.
Change-type: patch
Signed-off-by: Florin Sarbu <florin@balena.io>
It's not an official status from container inspects, and the Supervisor
doesn't set it internally anywhere. It's better to remove it entirely as the
method by which Supervisor sets internal service statuses is by using a global
event emitter (reportNewStatus) which makes things difficult to test.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
The previous implementation in #2170 of parsing the container status was too general,
because it relied on the mistaken assumption that a container would have a status of
`Stopped` if it was manually stopped. This turned out to be untrue, as manually stopped
containers were also getting restarted by the Supervisor due to their inspect status of
`exited`. With this, parsing the exit message became unavoidable as there are no other
clear ways to discern a container that has been manually stopped and shouldn't be started
from a container experiencing the Engine-host race condition issue (again, see #2170).
Since we're just parsing the exit error message, we don't need to worry about different behaviors
amongst restart policies, as any container with the error message on exit should be started.
Change-type: patch
Closes: #2178
Signed-off-by: Christina Ying Wang <christina@balena.io>
