The CI approach for generating and uploading containers for someip-feeder differs quite a lot from other components. Like we have sha*-tagged versions, we have an edge-version and latest point to latest merged commit, for other components typically to latest released version. Other components typically have a mainversion. The approach does not seem to be documented.
Proposal:
Investigate if a different approach is needed (compared to other components)
If not, agree that long term approach shall be aligned with other components
If so, agree on when/how to change handling. As long as we do not remove old releases old references will still work, but you might get a different result than expected (e.g. latest/edge not pointing to latest merged commit, but to something older)
If someip-feeder actually need a different approach - make sure that we document it, preferably with a rationale.
The CI approach for generating and uploading containers for someip-feeder differs quite a lot from other components. Like we have
sha*-tagged versions, we have anedge-version andlatestpoint to latest merged commit, for other components typically to latest released version. Other components typically have amainversion. The approach does not seem to be documented.Proposal:
https://github.com/eclipse/kuksa.val.feeders/blob/main/.github/workflows/someip2val_build.yml#L110 https://github.com/eclipse/kuksa.val.feeders/pkgs/container/kuksa.val.feeders%2Fsomeip-feeder