• Icon: Story Story
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • None
    • Operator
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • 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

              ocazade@redhat.com Olivier Cazade
              jtakvori Joel Takvorian
              None
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: