SiegfriedSiegert/PTU5KAS
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
f3521f82fa
PTU5KAS/.github/workflows/release.yml

46 lines
1.3 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: release
on:
push:
tags:
- '*.*'
jobs:
deploy_containers:
name: Build and deploy container images
runs-on: ubuntu-latest
steps:
- name: Check out repo
ci: Update to actions/checkout@v3 and actions/setup-python@v4 Silences some NodeJS 12 action deprecation warnings. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2023-01-05 20:17:20 +01:00
uses: actions/checkout@v3
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: Get release
ci: Switch to environment files 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>
2020-11-20 08:56:56 +01:00
run: echo "RELEASE_VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
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
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
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
tags: |
ghcr.io/siemens/kas/kas
ghcr.io/siemens/kas/kas:${{ env.RELEASE_VERSION }}
ghcr.io/siemens/kas/kas:latest-release
- name: Build kas-isar image
uses: docker/build-push-action@v2
with:
Dockerfile: Rework generation of kas images 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>
2022-08-26 14:34:37 +02:00
target: kas-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
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
tags: |
ghcr.io/siemens/kas/kas-isar
ghcr.io/siemens/kas/kas-isar:${{ env.RELEASE_VERSION }}
ghcr.io/siemens/kas/kas-isar:latest-release
Reference in New Issue Copy Permalink