Support syncing git-based sources

[exdx]

Most implementations of deploying a git repository inside a cluster have the ability to keep the repository up to date with changes to the remote. It makes sense to expand the current git source to include the ability to, optionally, keep the deployed version up to date.

For an example of a tool that supports this, see https://github.com/kubernetes/git-sync.

[timflannagan]

Thinking about briefly: we've traditionally been against encoding logic for handling bundles that specify an image-based source type and a container image tag, and automatically detecting new image digests. Would introducing this behavior for git-based bundles be a confusing UX, or is this something we'd expect to be delegated to individual provisioner implementations in the future anyways?

[awgreene]

We reviewed this ticket in the OLM Issue Triage Meeting, some notes:

• We need to provide provisioners with a Best Practices document.
• Historically RukPak has treated Bundles as immutable resources, changes to the bundle's spec are rejected.
• In this instance, the bundle.Spec would point to a tag and the provisioner would poll for a change and modify deployed content based on changes to the git tag. This could introduce issues where a Cluster Admin approved a bundle only to have the scope of the approved resources expanded due to a change in the git repository. As such, RukPak is strongly against provisioners polling and updating bundle content after it has been unpacked.

[github-actions[bot]]

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.