Tags: hazelcast/hazelcast-docker
Tags
Fix `check-base-images` (#1057) Since #1039, the [build is failing](https://github.com/hazelcast/hazelcast-docker/actions/runs/17090016143). This is because we are triggering the `push` actions like they are `composite` actions but they are actually reusable workflows. Changes: - refactored the action to calculate the required rebuilds and then trigger these as reusable workflows - i.e. in a separate `job`, not a nested `step` - non-trivial - but does at least give us the benefit that each of the rebuilds are done in parallel - ensure that `push` `docker-logs` have unique names - previously were executing in different jobs, but now are in the same one - overlapping names are not permitted - removed checking the NLC/EE images separately - they are the same image, if one needs rebuilding - they both do - `ee-nlc-tag-push` wasn't even a reusable workflow [Example execution](https://github.com/hazelcast/hazelcast-docker/actions/runs/17099726415).
Remove building image in `build-pr` as duplicated in `tag_image_push` (… …#1062) In `build-pr` we build test images and then run `simple-smoke-test`. We subsequently trigger `tag_image_push` (in `DRY_RUN` mode) which _also_ builds a test image and then runs `simple-smoke-test` on it (among other things). As such we should remove this duplication, and instead rely on the script _we actually use for release_. Post-merge actions: - [ ] [update branch protection rules](https://github.com/hazelcast/hazelcast-docker/settings/branch_protection_rules/24406088)
Execute `tag_image_push` actions from `master` [DI-581] (#1039) The `push` actions are automatically triggered on `push` events to their respective branches/tags, but the actions that are triggered are run on the branch themselves - which means that to support `N` maintenance versions, we end up supporting `N` copies of the build scripts. This also exposes further issues when trying to rebuild the images on a scheduled basis - GitHub does not support dynamic usage of re-usable workflows, so instead we have to trigger the actions on the specified branches via `gh` asynchronously and then lose all visibility of the execution outcome: https://github.com/hazelcast/hazelcast-docker/blob/36410467219c8215d538d4f28b4d0e2ed7a3cdb7/.github/workflows/check-base-images.yml#L96-L97 Update to execute from `master`, including using the latest scripts, actions etc - but to checkout the specified `ref` to use for the underlying `Dockerfile`. Changes: - `push` trigger removed - will require upstream pipeline changes - actions *must* be manually triggered - `SOURCE_REF` parameter added - specify the target `hazelcast-docker` branch - `HZ_VERSION` input removed - computed dynamically based on the specified branch - optional `RELEASE_VERSION` input removed - allowed releasing `hazelcast-docker` with a separate lifecycle (e.g. `5.5.1.1`), outside of the release of `hazelcast` (e.g. at `5.5.1`) - unsure if ever been used in production, adds cognitive overhead to pipeline [Example execution](https://github.com/hazelcast/hazelcast-docker/actions/runs/16818172462/). Fixes: [DI-581](https://hazelcast.atlassian.net/browse/DI-581) [DI-581]: https://hazelcast.atlassian.net/browse/DI-581?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Execute `tag_image_push` actions from `master` [DI-581] (#1039) The `push` actions are automatically triggered on `push` events to their respective branches/tags, but the actions that are triggered are run on the branch themselves - which means that to support `N` maintenance versions, we end up supporting `N` copies of the build scripts. This also exposes further issues when trying to rebuild the images on a scheduled basis - GitHub does not support dynamic usage of re-usable workflows, so instead we have to trigger the actions on the specified branches via `gh` asynchronously and then lose all visibility of the execution outcome: https://github.com/hazelcast/hazelcast-docker/blob/36410467219c8215d538d4f28b4d0e2ed7a3cdb7/.github/workflows/check-base-images.yml#L96-L97 Update to execute from `master`, including using the latest scripts, actions etc - but to checkout the specified `ref` to use for the underlying `Dockerfile`. Changes: - `push` trigger removed - will require upstream pipeline changes - actions *must* be manually triggered - `SOURCE_REF` parameter added - specify the target `hazelcast-docker` branch - `HZ_VERSION` input removed - computed dynamically based on the specified branch - optional `RELEASE_VERSION` input removed - allowed releasing `hazelcast-docker` with a separate lifecycle (e.g. `5.5.1.1`), outside of the release of `hazelcast` (e.g. at `5.5.1`) - unsure if ever been used in production, adds cognitive overhead to pipeline [Example execution](https://github.com/hazelcast/hazelcast-docker/actions/runs/16818172462/). Fixes: [DI-581](https://hazelcast.atlassian.net/browse/DI-581) [DI-581]: https://hazelcast.atlassian.net/browse/DI-581?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Fix `publish-rhel` [5.3.8] (#1000) The [action failed](https://github.com/hazelcast/hazelcast-docker/actions/runs/15868710042) with: > .github/scripts/publish-rhel.sh: line 32: VERSION: unbound variable The root cause was that when #968 was backported, there were _additional_ `5.3.8`-specific changes it wasn't accounting for (e.g. #799 which was _not_ backported from `5.3.z` -> `5.3.8`). Fixed by copying _wholesale_ the `5.3.z` `publish-rhel` script. [Example execution](https://github.com/hazelcast/hazelcast-docker/actions/runs/15869851560).
Fix RHEL build failure due to backport error [5.4.1] (#989) There was a [RHEL build failure](https://github.com/hazelcast/hazelcast-docker/actions/runs/15559031202) caused by an error introduced into _only_ `5.4.1` due to a backport conflict. Addressed by copying the problematic functions from the `5.4.z` script. [Example (successful) execution](https://github.com/hazelcast/hazelcast-docker/actions/runs/15564480718).
PreviousNext