Under some conditions, an aarch64 device may get a reference to a armv7hf
supervisor on the target state. One of the ways this can happen is if
an aarch64 device is added to an armv7hf fleet and the target supervisor
is set before the device fully provisions.
If that happens, the previous filtering for the supervisor app (which
relied on the architecture in device-type.json) would
fail and the user would end up with two supervisor containers, one
running correctly and the other crash looping.
This fixes the filtering and just checks if the supervisor uuid/service
name belongs to a group of known uuids.
Closes: #2006
Change-type: patch
The supervisor uses the following pattern for async module
initialization
```typescript
// module.ts
export const initialised = (async () => {
// do some async initialization
})();
// somewhere else
import * as module from 'module';
async function setup() {
await module.initialise;
}
```
The above pattern means that whenever the module is imported, the
initialisation procedure will be ran, which is an anti-pattern.
This converts any instance of this pattern into a function
```typescript
export const initialised = _.once(async () => {
// do some async initialization
});
```
And anywhere else on the code it replaces the call with a
```typescript
await module.initialised();
```
Change-type: patch
This allows to run integration tests during development and on CI
with the right dependencies. There are several changes that this
involves, but the gist of it is that a test environment is setup using
`docker-compose.test.yml`. This file is loaded by `resin-ci` during the
build, and ensures that integration tests are ran after setting up all
requirements. This commit also defines a test environment command that
can be setup using `npm run test:env` in order to run tests in a local
development machine.
This sets up the new `test/unit` and `test/integration` folders
and starts classification of some of the test files.
Note that unit tests include, `fs-utils` and `system-info` tests.
While these tests interact with the filesystem, the implementation
of these modules is simple enough, and the tests are fast enough to
allow these tests to fall under the `unit` test category (according to
test/README)
Change-type: patch
We are refactoring the supervisor test suite into unit tests (for
algorithms an domain model tests) and integration
tests (for interaction with out-of-process dependencies).
This means the current test suite needs to be classified into
these two categories, and fixed whenever possible.
This commit moves the test suite under the `test/legacy` folder, this
folder should be progressively migrated and eventually removed.
Subsequent commits will begin to split these files into unit and
integration whenever possible.
Depends-on: #1996
Change-type: patch
This replaces all relative paths in the test suite (e.g
`../src/compose/service.ts`) with the aliased path configured through
tsconfig.
This is a big change but it doesn't affect any functionality
Currently, tests only can import source code modules through relative
paths `../../`. This makes it very difficult to refactor and organize
tests in folders as the paths change.
[tsconfig-paths](https://www.npmjs.com/package/tsconfig-paths) allows to
reference the source through an alias defined in the "paths" section of
tsconfig.json
The supervisor used to perform tests both for the transpiled code (after
tsc) and one for the typescript code (using
ts-node/register/transpile-only). There is not really a reason for this
and this added complexity to the test configuration. This used to make
testing harder, as the built code didn't include source maps, meaning
the tests did not point to the right code.
Since we want to split tests in unit and integration tests as the next
test improvement, it makes sense to simplify these commands before
adding more complexity.
Change-type: patch
This mitigates an edge case bug introduced in v13.1.3 where services that
are slow to exit may get stuck in a state of Downloaded if a service var is
changed then reverted rapidly. More detailed description in linked issue.
Change-type: patch
Closes: #1991
Signed-off-by: Christina Wang <christina@balena.io>
State report errors contribute to the supervisor failing healthchecks
and being restarted by the engine. There is not evidence of this
improving the connectivity situation and it is likely to make things
worst for the API as the first report is much more expensive than
subsequent partial reports.
Change-type: patch
Closes: #1986
Restructure the supervisor image to remove the dependency on the custom `alpine-supervisor-base`
image and the custom node build. The dockerfile is now a multi-stage
build that splits the process into two build stages and two runtime
stages.
Here is the full list of changes
- The node binary is now copied from `balenalib/${ARCH}-alpine-node:12-run`, the node binary
now supports running with a debugger.
- The runtime image now inherits from the official `alpine:3.16` image
- Tests are ran within the runtime image configuration instead of the
build image
- Livepush is ran within the runtime image context
- Unnecessary packages have been removed
- Removed avahi-daemon.conf as that service is not being used
- Fix livepush to work with a multi-stage image. This also deprecates the `image-tag` argument to npm run sync as
`SUPERVISOR_TAG` is no longer used by new OSs
- Fix livepush build on old rpi devices. Allows passing a 'PREFIX'
argument to let the builder pull images directly from docker hub arch
repositories. Relates to https://github.com/balena-os/balena-engine/issues/269
Change-type: patch
Some libraries, like [proper-lockfile](https://www.npmjs.com/package/proper-lockfile)
use directories instead of files for locking. This PR allows the supervisor to be able to
work with those types of locks when lock override is requested.
Closes: #1978
Change-type: patch
Host config shouldn't be tied to applications in the first place, but
needs to be done so because it uses update locks to determine when it's
safe to patch host config, and update locks are tied to apps.
Change-type: patch
Signed-off-by: Christina Wang <christina@balena.io>
There is no functionality which 1) stores the filesystem lock status when toggling override
to on, and 2) restore the system to that status when toggling override to off.
Change-type: patch
Signed-off-by: Christina Wang <christina@balena.io>
