ci(docker): images should have independent major minor tags

[bosbaber]

Summary

This PR refactors the image building, tagging and pushing github actions so that an appropriate hierarchy of tags are created.

These changes was extensively tested on a fork under my personal github account. You can view the actions logs here.

Changes proposed in this pull request

• Tag independent minor and major docker images on releases
• Refactoring of CI workflow
• Performance test CI job modified to skip automatic commenting if PR is from a fork like this one

On releasing of new version v1.1.1

• images created and pushed for the following tags
  • package_name v1.1.1
  • package_name v1.1
  • package_name v1

On releasing of new version v1.1.1-beta

• images created and pushed for the following tags

  • package_name v1.1.1-beta
  • package_name v1.1-beta
  • package_name v1-beta

  If any of the of the minor or major tags already exist we will simply override them.

Context

Last week there was a minor bug which caused various issues in testnet. Unfortunately the rafiki charts are currently pinned to a very specific version which meant we had to make changes to both the charts and terraform repositories in order to deploy a new version of the chart to solve the problem.

I had the thought that we should probably pin the appVersion associated with specific Helm charts to the most recent stable minor version of our releases. This will allow consumers like testnet to have bug fix patch updates to the most recent minor version. Users that want more control can use the versionOverride feature of the rafiki helm charts to pin to the specific patch version they desire.

There are many environments in which you do not want to pin your application to a specific patch version, but rather to a minor or patch version. Docker images being generated at the moment have exact tags and for this reason many consumers would want to be able to pin to just a minor or major version.

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Make sure that all checks pass
• Bruno collection updated (if necessary)
• Documentation issue created with user-docs label (if necessary)
• OpenAPI specs updated (if necessary)

[netlify]

✅ Deploy Preview for brilliant-pasca-3e80ec canceled.

Name	Link
🔨 Latest commit	6b1c572
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/6828f63b49e58a000898c923

[mkurapov]

has_hierarchy is always equal to generateRelease, correct? We can also just pass generateRelease through instead

[bosbaber]

After finally circling back to this PR your comment prodded me to rethink if the concept of generateRelease even makes sense here. Then that forced me to stare a bug in the face which has now been resolved.

In short, the purpose of this function is to decide if we need an hierarchical version based on the version name. Versions 'nightly' should definitely push, but has no hierarchy. generateRelease makes no sense here so I removed it instead.

I updated functions accordingly and tested pipelines on my private repo.

[Copilot]

Pull Request Overview

This PR refactors the CI workflows and custom actions for building, tagging, and pushing Docker images so that independent minor and major tags are generated based on the version.

• The node-build workflow now only posts performance test results on pull requests and skips automatic comments for forked PRs.
• The GitHub actions for calculating version hierarchy, pushing manifests, and re-tagging images have been introduced or updated to support the new tagging hierarchy.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
.github/workflows/node-build.yml	Updated performance test result posting logic and refactored docker push steps to utilize a custom image-push action.
.github/actions/parent-versions/action.yml	New composite action to calculate version hierarchy based on semantic version strings.
.github/actions/manifest-push/action.yml	New composite action to create and push multi-arch manifest lists with parent version tags.
.github/actions/image-push/action.yml	New composite action to load, tag, and push docker images including parent version tags.

Comments suppressed due to low confidence (1)

.github/actions/image-push/action.yml:63

• [nitpick] Consider revisiting the formatting of the image tag string for clarity. In particular, ensure consistent spacing inside the interpolation of 'inputs.app_name' to aid readability, even if the current formatting is functionally acceptable.

docker tag ghcr.io/${{ github.repository_owner }}/${{ inputs.app_name}}-${{ inputs.package }}-${{ inputs.platform_name }}:${{ inputs.version }} ghcr.io/${{ github.repository_owner }}/${{ inputs.app_name}}-${{ inputs.package }}-${{ inputs.platform_name }}:${{ steps.hierarchy.outputs.major_parent }}