The Gitea operator is discussed and installed in the ACM part

[adelton]

Factoring out my comment from already merged pull request: #30 (comment):

The Gitea operator and repo setup was added to the ACM part and not to the pipelines. Before #30 got merged, the only mention of gitea in the ACM part was acm/registration/near-edge/overlays/bike-rental-app/kustomization.yaml and acm/registration/near-edge/overlays/tensorflow-housing-app/kustomization.yaml, and those were updated by the PipelineRuns in the GitOps pipeline.

The pull request also added to README

The gitea-operator will be installed on the odh-core cluster as part of the ACM application rollout.

But if the GitOps pipeline is to work with Gitea repositories stored in this cluster, surely the Gitea repositories (and therefore the operator) have to exist before the GitOps pipeline runs.

(I talk about the PoC in general, not about the instance at *.rhoai-edge-acm-poc.*.)

In #123 I'm making the GitOps pipeline actually work with GitHub, so partially related question is -- do we allow the demo to run solely with git repositories on GitHub (making Gitea optional), or is Gitea now mandatory?

[LaVLaS]

After setting up a brand new cluster for this use case, I fully admit fault in merging that gitea-operator PR prematurely. I now think that operator subscriptions or only the gitea-operator & gitea instance should be included as a use case pre-requisite before we deploy the PoC.

Having this git server in place prior to the the first steps of ACM registration would allow us to set the GitOps urls and workflows for the in cluster gitea server before we ACM applications.

I updated #116 to reflect that gitea deployment should be removed from the ACM deployment and moved to the Makefile so that the expected workflow for this use case

1. Provision Cluster
2. Run make deploy-gitea
3. Fork github/opendatahub-io/ai-edge -- gitea/edge-user/ai-edge
4. Update gitea/edge-user/ai-edge to point to this gitea server instance
5. Install ACM
6. Run ACM registration that points to our gitea server

[adelton]

But this still does not address the pipelines part of the story. If the git repo is not set up when the GitOps pipeline runs, that pipeline run won't be able to file a pull request to update the container image SHA-256 to the newly built and pushed one.

[adelton]

Can you please also comment on the GitHub part of the question? Why do we set up Gitea as mandatory at all? I mean, it can be a reasonable optional step that could be documented as such, but why do we force people to deal with Gitea at all in the PoC?

[adelton]

For the record, the latest changes in main default to GitHub. The Gitea operator part stays in README.md for the time being, but should likely be moved to some separate document, and referenced from the respective parts of README.md and pipelines/README.md in the "if you'd like to use your own git server instead of GitHub, you might want to check Gitea" manner.