Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions .github/workflows/push.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# SPDX-License-Identifier: Apache-2.0
# Copyright 2024 Intel Corporation
# Copyright 2025 Canonical Ltd.
name: Release Pipeline

on:
push:
branches:
- main
paths:
- "VERSION"

permissions:
contents: read

jobs:
# CAUTION: Other actions depend on this name "tag-github"
tag-github:
uses: onosproject/.github/.github/workflows/tag-github.yml@main
secrets: inherit

release-image:
needs: tag-github
if: needs.tag-github.outputs.changed == 'true'
permissions:
contents: read
packages: write
actions: read
id-token: write
attestations: write
uses: onosproject/.github/.github/workflows/release-image.yml@main
with:
# Prefix the version with 'v' to follow tagging conventions
docker_tag: v${{ needs.tag-github.outputs.version }}
secrets: inherit

update-version:
needs: tag-github
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gemini highlighted a "Parallel Execution" Risk

Currently, release-image and update-version run in parallel because they both only depend on tag-github.

The Problem: If release-image fails (e.g., Docker registry is down, build error), update-version might still succeed. The Result: Your repository will bump the version (e.g., to 1.2.4-SNAPSHOT), but the artifact for 1.2.3 was never published. You end up in a "zombie state" where the git history says the release is done, but the container registry is empty.

The Fix: Make update-version depend on the success of release-image.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I partially agree with this comment/suggestion. What happens if the release-image fail? Image is not published and VERSION is NOT updated (update-version does not run). So, you have to manually (re)trigger the release-image action again until it is successful and then you need to manually trigger the update-version action.
On the other hand, if we leave the parallelism there, update-version will always run (based on tag-github) and you have to manually (re)trigger the release-image action if needed, which is the approach we took for the sd-core

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As @gab-arrobo points out, it's not entirely clear what is the ideal behavior if the release_image job fails. It sounds like leaving as-is will at least keep the behavior consistent with sd-core so I'm inclined to do that.

if: needs.tag-github.outputs.changed == 'true'
uses: onosproject/.github/.github/workflows/bump-version.yml@main
secrets: inherit
with:
# Prefix the version with 'v' to follow tagging conventions
version: v${{ needs.tag-github.outputs.version }}
8 changes: 8 additions & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -179,6 +179,14 @@ aether-roc-api-docker: # @HELP build aether-roc-api Docker image
-t ${DOCKER_IMAGENAME_API}
@rm -rf vendor

# Docker targets for compatibility with GitHub workflow
docker-build: # @HELP build Docker image
docker-build: images

docker-push: # @HELP push Docker image
docker-push:
docker push ${DOCKER_IMAGENAME_API}

images: # @HELP build all Docker images
images: build aether-roc-api-docker

Expand Down
Loading