Only Ubuntu 20.04 is still supported with 3.5 and 3.6, so pin to it.
Expand the test to 3.10 and 3.11 at this chance. Quoting is needed now
to avoid that 3.10 becomes 3.1.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
While kas and kas-isar surely have a common ground like the kas tool
itself, kas-isar does not need all the toolchain packages that are
essential Yocto dependencies. Splitting up the images earlier allows to
shrink kas-isar by almost 400 MB.
Use this chance to model both images as different build stages of the
same Dockerfile. That is simpler than creating a temporary "kas-base"
image via a separate Dockerfile.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Break up the build into two stages, performing basic tests with poky and
isar on the two kas container types before uploading them. The tests
consist of building zlib-native with poky and cowsay for x86 bullseye
with Isar.
Note that the ordering "build kas", "test kas", "push kas",
"build kas-isar" is important because "build kas-isar" will not use the
locally built and imported kas:next image and rather pull the previous
one from the registry.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This checks basic features of kas menu, some option selection, yaml
including, rebuilding and target selection.
The UI is operated by mocking smack's GridFormHelp.runOnce and some
result evaluation functions. Injecting keys from the keyboard was not
easily possibly (if at all), thus this approach. The menu rendering is
not shown due to pytest.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This avoids pulling in anything unexpected and then running it as part
of the test and later on image build process.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Create the kas and kas-isar containers also for arm64. This allows using
them for arm-native builds, e.g. in AWS instances.
We need to drop a couple of packages from arm64 images which do not
exist on that arch. If the kas image is usable for Yocto builds is
untested, though. The Isar image works.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Refactor the workflows so that we can use build-push-action also for
publishing. This is a precondition for switching to buildx, needed for
multi-arch images.
The trick needed for this is using an environment variable to control
whether we should push when building the master branch, initializing it
according to the tag status.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Fixes:
"Unable to process command '::set-env name=RELEASE_VERSION::2.3'
successfully.
The `set-env` command is disabled. Please upgrade to using Environment
Files [...]."
To make the next release smoother, hopefully.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Add the github/ghcr equivalent to travis/dockerhub. With this in place,
we can also deploy the next and latest images to ghcr. Adjust
Dockerfile.isar accordingly. Also update the badge shown in the README.
We model the workflow with github a bit differently than so far: next
and master branch are different workflows. The former includes testing,
the latter just updates the container image. This is based on the
(offline) workflow to push changes to next first and have no commits
in master that haven't been in next before, except for release commits.
The master workflow also triggers on tags in which case it additionally
tags the container images accordingly and pushed that as well.
Travis is removed in the same run to avoid pushing differently built
images to the different registries.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
