-
Story
-
Resolution: Done
-
Undefined
-
None
-
None
-
None
-
None
-
False
-
-
False
-
None
-
None
-
None
-
NetObserv - Sprint 268, NetObserv - Sprint 269
FBC should be in their own repo to decorrelate them from release branching
We must also find a way to better handle nudging from operator (bundle) release branches.
E.g: nudging from operator-bundle:release-1.8 should affect only the 1.8 bundle referenced in FBC, and in parallel we should also accept nudging from operator-bundle:main to the "next" bundle referenced in FBC.
I think what we could do is to change this structure in `catalog` directory:
catalog |-- released | |-- 1.0.0.yaml | |-- 1.1.0.yaml | \-- etc. |-- index.yaml \-- rc.yaml
into this:
catalog
|-- released
| |-- 1.0.0.yaml
| |-- 1.1.0.yaml
| |-- etc.
| \-- index.yaml // last released index
\-- candidates
|-- 1.8.0.yaml
|-- 1.8.0-index.yaml // index that adds 1.8
|-- 1.8.0-bundle_digest.sh
|-- main.yaml
|-- main-index.yaml // index that adds main
\-- main-bundle_digest.sh
So we can have several candidates in parallel
But for nudging we still need to find a way to make them point to the correct xxx-bundle_digest.sh