The Docker Flowzone CI job currently only runs successfully
with `Dockerfile` and not any variants, by design.
Signed-off-by: Christina Ying Wang <christina@balena.io>
Replace test with test:base to make sure integration tests don't run in CI.
Integration tests for the Supervisor fail when not run in container, leading
to an error-exit and cause the Flowzone CI job for Node to fail.
By returning true, the Flowzone Node CI job succeeds, and this is fine even if tests
fail because they will be caught in the Docker job anyway.
Also, combine original npm test script with test:node.
Signed-off-by: Christina Ying Wang <christina@balena.io>
The supervisor supports target state `running: false` for services.
This state indicates that the service should be stopped if already
running, or that the container should just be created and never started
if the container does not exist. This commit fixes the latter behavior.
Although nothing in our platform currently sends this target state, this
enables some potential use cases, e.g. only starting some services
in manufacturing and starting the rest of the services when the device
actually connects.
Change-type: patch
Closes: #2014
`withDefault` is a type helper that allows to create a type that
defaults to a default value when trying to decode a nullish value.
That type was not correctly working with boolean types, causing `false`
values to be replaced by true. This would specifically cause issues when
parsing the target state, where a `running: false` in a service would
become a `running: true` due to the type decoding.
Change-type: patch
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
