SiegfriedSiegert/PTU5KAS
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
54ab356f9f
PTU5KAS/.github/workflows/next.yml

115 lines
4.0 KiB
YAML
Raw Normal View History

Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
name: next
on:
push:
branches:
- next
env:
SHELLCHECK_VERSION: v0.7.1
ci: Validate shellcheck archive 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>
2021-10-09 14:58:34 +02:00
SHELLCHECK_SHA256: 64f17152d96d7ec261ad3086ed42d18232fcb65148b44571b564d688269d36c8
tests: Add basic tests for menu plugin 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>
2021-10-08 17:24:46 +02:00
NEWT_VERSION: 0.52.21
NEWT_SHA256: 265eb46b55d7eaeb887fca7a1d51fe115658882dfe148164b6c49fccac5abb31
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
jobs:
perform_tests:
name: Run tests on kas code
runs-on: ubuntu-latest
strategy:
matrix:
ci: Add Python 3.9 to test matrix Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2020-11-13 08:02:24 +01:00
python-version: [3.5, 3.6, 3.7, 3.8, 3.9]
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
steps:
- name: Check out repo
uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python-version }}
architecture: x64
- name: Install Python dependencies of kas and tests
run: |
# install kas to have all kas dependencies:
pip install .
# checkcode dependencies:
pip install flake8 pycodestyle doc8 Pygments
# test dependencies:
pip install -U pytest
- name: Install recent shellcheck
run: |
wget -q https://github.com/koalaman/shellcheck/releases/download/$SHELLCHECK_VERSION/shellcheck-$SHELLCHECK_VERSION.linux.x86_64.tar.xz
ci: Validate shellcheck archive 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>
2021-10-09 14:58:34 +02:00
echo "$SHELLCHECK_SHA256 shellcheck-$SHELLCHECK_VERSION.linux.x86_64.tar.xz" | sha256sum -c
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
tar -xJf shellcheck-$SHELLCHECK_VERSION.linux.x86_64.tar.xz
sudo cp shellcheck-$SHELLCHECK_VERSION/shellcheck /usr/local/bin/
tests: Add basic tests for menu plugin 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>
2021-10-08 17:24:46 +02:00
- name: Install python-newt
run: |
sudo apt-get update
sudo apt-get install libpopt-dev libslang2-dev
wget -q https://releases.pagure.org/newt/newt-$NEWT_VERSION.tar.gz
echo "$NEWT_SHA256 newt-$NEWT_VERSION.tar.gz" | sha256sum -c
tar -C /tmp -xzf newt-$NEWT_VERSION.tar.gz
cd /tmp/newt-$NEWT_VERSION
autoconf
./configure --with-python=python${{ matrix.python-version }}
make -j $(nproc)
sudo make install
ln -s /usr/local/lib/python${{ matrix.python-version }}/site-packages/_snack.so \
$(python3 -c 'import site; print(site.getsitepackages()[0])')/
ln -s /usr/local/lib/python${{ matrix.python-version }}/site-packages/snack.py \
$(python3 -c 'import site; print(site.getsitepackages()[0])')/
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
- name: Run tests
run: |
scripts/checkcode.sh .
tests: Add basic tests for menu plugin 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>
2021-10-08 17:24:46 +02:00
TERM=xterm pytest
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
ci: Add basic tests for built kas and kas-isar containers 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>
2022-01-11 19:30:30 +01:00
build_containers:
name: Build, test and deploy container images
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
needs: perform_tests
runs-on: ubuntu-latest
steps:
- name: Check out repo
uses: actions/checkout@v2
Add support for multi-arch containers 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>
2021-01-02 19:49:39 +01:00
- name: Set up QEMU
uses: docker/setup-qemu-action@v1
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
- name: Login to ghcr.io
uses: docker/login-action@v1
with:
registry: ghcr.io
username: ${{ secrets.PACKAGE_DEPLOY_USER }}
password: ${{ secrets.PACKAGE_DEPLOY_TOKEN }}
- name: Build kas image
ci: Add basic tests for built kas and kas-isar containers 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>
2022-01-11 19:30:30 +01:00
uses: docker/build-push-action@v2
with:
load: true
tags: ghcr.io/siemens/kas/kas:next
- name: Test kas image
run: |
cd image-tests/poky
KAS_IMAGE_VERSION=next ../../kas-container build kas.yml
- name: Complete build and deploy kas image
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
uses: docker/build-push-action@v2
with:
Add support for multi-arch containers 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>
2021-01-02 19:49:39 +01:00
platforms: linux/amd64,linux/arm64
ci: Push directly from build step 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>
2021-01-02 18:50:34 +01:00
tags: ghcr.io/siemens/kas/kas:next
ci: Add basic tests for built kas and kas-isar containers 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>
2022-01-11 19:30:30 +01:00
push: true
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
- name: Build kas-isar image
ci: Add basic tests for built kas and kas-isar containers 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>
2022-01-11 19:30:30 +01:00
uses: docker/build-push-action@v2
with:
file: Dockerfile.isar
load: true
build-args: KAS_TAG=next
tags: ghcr.io/siemens/kas/kas-isar:next
- name: Test kas-isar image
run: |
cd image-tests/isar
KAS_IMAGE_VERSION=next ../../kas-container build kas.yml
- name: Complete build and deploy kas-isar image
Switch to github workflow 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>
2020-09-23 11:36:12 +02:00
uses: docker/build-push-action@v2
with:
file: Dockerfile.isar
Add support for multi-arch containers 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>
2021-01-02 19:49:39 +01:00
platforms: linux/amd64,linux/arm64
ci: Push directly from build step 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>
2021-01-02 18:50:34 +01:00
build-args: KAS_TAG=next
tags: ghcr.io/siemens/kas/kas-isar:next
ci: Add basic tests for built kas and kas-isar containers 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>
2022-01-11 19:30:30 +01:00
push: true
Reference in New Issue Copy Permalink