[FEATURE]: With the gitRepoBranchBase in pipelines, matching mechanism is needed in the ACM part

[adelton]

Details

Is your feature request related to a problem? Please describe.

PR #135 by @LaVLaS introduced gitRepoBranchBase to the GitOps Pipeline to be able to file pull requests with updated container image information in non-default branches.

However, if those GitOps configuration changes end up in a repo in a non-default branch, the ACM Channel / Subscription configuration should be possible to use that same non-default branch.

Describe the use-case or expected workflow

• A pull request is made by the GitOps PipelineRun to my git repo and branch prod which is not the default branch in my repo.
• I merge that pull request to that branch prod.
• I expect my ACM-deployed applications to deploy from prod.

However, the acm/registration/near-edge/overlays/*-app/kustomization.yaml currently do not show how to achieve that. The acm/registration/near-edge/base/near-edge.yaml contains

apps.open-cluster-management.io/git-branch: main

Describe alternatives you've considered

None.

Additional context

[grdryn]

Do the instructions in the ACM section of DEVELOPMENT.md cover what you're looking for?

I had only considered that mechanism for development/testing setup, with an implicit expectation that if people forked the repo and wanted to use a different branch for some sort of production case, that they'd update the values that they needed. Do you think documentation would be a good solution to this?

I'd hope that as we start to figure out how to integrate things more into ODH, that we'd find a more intuitive way to configure things like this.

[adelton]

Do the instructions in the ACM section of DEVELOPMENT.md cover what you're looking for?

They don't really. Neither of the README.mds uses make, so suddenly using that instead of editing files and running oc does not fit into the demo/PoC concept of "I will follow the steps and hopefully understand what is being set up and done".

Furthermore, nowhere is there explained relationship of the test/ directory to the rest of the repository.

I had only considered that mechanism for development/testing setup, with an implicit expectation that if people forked the repo and wanted to use a different branch for some sort of production case, that they'd update the values that they needed. Do you think documentation would be a good solution to this?

We now have a way to file the PRs from the GitOps pipeline in a nonstandard branch. I have no idea how important it was to do that but the mechanism is there, it is documented in https://github.com/opendatahub-io/ai-edge/tree/main/pipelines#git-repository-and-credentials ... and if you modify the nonstandard branch in pipelines, chances are you want to consume those changes in the ACM part.

I'm looking for an end-to-end experience.

I don't really care how it's done. If #110 is addressed and all the steps in the README.mds get changed to use make, that is is general fine with me. (Even if as a demo / PoC repo, it adds a layer of indirection that a user or developer needs to untangle if they want to do something nonstandard.)

But I find it weird to use a mechanism that is not used anywhere for that second stage of moving to nonstandard branch. :-)