Consider integrating with fluxcd for source tracking

[derrickburns]

If I understand the Pulumi Kubernetes operator correctly, it executes Pulumi updates by pulling code from Git from within Kubernetes.

For this application, you may want to consider integrating with FluxCD v2. It provides the tracking of Git repos for changes that appears to be missing from the Pulumi operator.

[lukehoban]

Indeed! This is largely what is being tracking in #50, so I'll close this out as a dupe of that. I added the more explicit note there that the likely approach we'll want to take is to build on the support for Git polling that already exists in a reusable form in Flux or Argo.

[viveklak]

Breaking out the suggestion to use flux etc. from #50 here instead. Some possibilities here include integrating with https://fluxcd.io/docs/components/source/gitrepositories/. This could allow users to choose to install the Flux Source Controller to use that or the Bucket source as a source for content that triggers reconciliation in the operator.

[squaremo]

Here's a quick summary of what I see as the pros and cons of having an integration with Flux2 "sources" (GitRepository, Bucket)

Pros

1. the fiddliness of working with go-git and libgit2 is kept to one place (and not here)
2. people can use Flux's notification-controller to support incoming webhooks for e.g., commit notifications
3. ditto instrumentation and outgoing notifications (e.g., to Slack)
4. supporting new kinds of source that get added to Flux will be a marginal cost here (for instance, OCI images per https://github.com/fluxcd/flux2/pull/2601)

Cons

1. a dependency means ongoing work to keep up with releases, API changes, and so on
2. it's extra work for a user to run Flux components as well
3. if the "native" git support is kept, then there's two ways of doing not quite the same thing
4. if this replaces the native git support, then everyone has to migrate

On Pro 1.), there is a middle ground of using Flux's libraries (fluxcd/pkg) to deal with git. The support for git code relies on pulumi/pulumi, so either the support here would use fluxcd/pkg directly, or the library there would be rewritten to use fluxcd/pkg.

[viveklak]

An added benefit here is to leverage support for a variety of source control providers which have been known to cause problems with go-git - the library that the underlying automation api uses for git integration. See #302 and #286 for instance.

[lblackstone]

Fixed in https://github.com/pulumi/pulumi-kubernetes-operator/pull/324. See https://www.pulumi.com/blog/pulumi-kubernetes-new-2022/ for details.