[Flake] Unpacking bundles with git sources
See https://github.com/operator-framework/rukpak/runs/6176813469?check_suite_focus=true for an example of a CI run where the git unpacking fails due to a timeout. Needs to be triaged further to understand why and possible fixes.
@exdx I'm going to mark you as the assignee for now while I'm briefly grooming the 0.4 milestone. We can re-assign this as necessary if case anyone else wants to tackle triaging and/or fixing this flake.
Looking at ways to address this by changing the git source repository from a public github repository to something self hosted or more internal to the project. This would be more in-line with the other image-based tests which are hermetic. Unfortunately, I'm not finding any good implementations of a simple git server in go. I've looked at gogs and git-go, neither of which really fit the use-case. I'm wary of writing a simple http server that can serve repositories since it needs to use the git protocol which is complex.
It's also possible to simply mount the test git bundles as files available somewhere in the cluster and reference the repository by a path instead of a URL. Not sure how to do this though.
@exdx It looks like git allows remotes using the file:/// protocol for "local" remotes. I think that might be our ticket here.
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_local_protocol
Not sure how to do this though.
Yeah, I guess that's the tough part. How do we get that into the unpack pod? The obvious answer is a volume mounting a local path, but its not obvious how to get the Bundle controller to inject that.
Something along these lines maybe: https://hub.docker.com/r/jkarlos/git-server-docker/
Suggestion: move this flake to the backlog as it's unclear how often we're running into it right now, and create a ticket dedicated towards trying to use "local" git remotes for our e2e testing purposes like we currently do with image-based Bundle source types.
Nick: https://github.com/gogs/gogs worth investigating?
This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.
In a recent PR by @akihikokuroda we wrote out some logic that allows us to deploy a on-cluster git server for E2E testing. Once that merges we'll want a follow-up that converts the existing tests to utilize that server and we should reevaluate this issue at that time.
https://github.com/operator-framework/rukpak/pull/586
This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.