Adding azdoPrRepoName as metadata in FluxCD alert

[cyberjpb1]

I added a metadata in the alert definition of the gitops-connector to be able to identify the name of the repo corresponding to the PR. This modification allowed me to support my scenario where I have a manifest repo per application.

spec:
 eventMetadata:
  azdoPrRepoName: WebApp1

I should mention that I don't know the Python language and I went with the logic of the existing code so don't judge my code too harshly.

apiVersion: notification.toolkit.fluxcd.io/v1beta2
kind: Provider
metadata:
  name: webappexemple-gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
---
apiVersion: notification.toolkit.fluxcd.io/v1beta2
kind: Alert
metadata:
  name: webappexemple-gitops-connector
  namespace: flux-system
spec:
  eventMetadata:
    azdoPrRepoName: WebApp1
  eventSeverity: info
  providerRef:
    name: webappexemple-gitops-connector
  eventSources:
    - kind: GitRepository
      name: webappexemple-source
    - kind: Kustomization
      name: webappexemple-kustomization

[eedorenko]

The GitOps connector instance is shared across threads. It is very possible that another thread, initiated by an alert configured for the different application/repo, will override these self settings. So the message from thread 1 will go to the repo from thread 2.

[eedorenko]

Besides forwarding the alerts to AZDO, GitOps connector detects abandoned/rejected PRs to the GitOps repo and notifies the agentless waiting task to fail, so the whole promotional flow gets failed. This logic is implemented on top of having a single repo.

IMO, if we want to support multiple applications, we have the options:

• Have an instance of GitOps Connector per application
• Enhance the GitOps Connector to be configured with multiple repos (e.g. in config maps) and like you suggested, reference these repos in the alert definition

[cyberjpb1]

Thanks for the review, so I'm closing the Pull Request.