Experimental support for argocd action to deploy the argo app

[rgolangh]

This is a WIP to make the basic template use the argocd create-resources action so
if RHDH have the argocd scaffolder plugin enabled and configured we can immediately deploy
that argocd app.

The result should be a workflow which is immediatly built and deployed and after deployment available in the orchestrator overview page.

Signed-off-by: Roy Golan rgolan@redhat.com

[masayag]

Is the main instance name the same as the one defined in the plugin configuraiton at
https://github.com/parodos-dev/orchestrator-helm-chart/blob/main/charts/orchestrator/templates/rhdh-operator.yaml#L185 ?

[masayag]

@rgolangh when this one verified, it closes https://issues.redhat.com/browse/FLPATH-1322
Pls don't hesitate to assign it to you :-)

[masayag]

There needs to be two applications, one for each component:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: yfassess
  namespace: orchestrator-gitops
  labels:
    app-type: bootstrap
    app: yfassess
spec:
  destination:
    namespace: sonataflow-infra
    server: https://kubernetes.default.svc
  project: orchestrator-gitops
  source:
    path: argocd
    repoURL: git@github.com:test-workflows/yfassess.git
    targetRevision: HEAD
  syncPolicy:
    automated:
      # Keep history of pipeline runs
      prune: false
      selfHeal: true

and

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: yfassess-gitops
  namespace: orchestrator-gitops
  labels:
    app-type: workflow
    app: yfassess
spec:
  destination:
    namespace: sonataflow-infra
    server: https://kubernetes.default.svc
  project: orchestrator-gitops
  source:
    path: ./kustomize/base
    repoURL: git@github.com:test-workflows/yfassess-gitops.git
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

[rgolangh]

There needs to be two applications, one for each component:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: yfassess
  namespace: orchestrator-gitops
  labels:
    app-type: bootstrap
    app: yfassess
spec:
  destination:
    namespace: sonataflow-infra
    server: https://kubernetes.default.svc
  project: orchestrator-gitops
  source:
    path: argocd
    repoURL: git@github.com:test-workflows/yfassess.git
    targetRevision: HEAD
  syncPolicy:
    automated:
      # Keep history of pipeline runs
      prune: false
      selfHeal: true

and

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: yfassess-gitops
  namespace: orchestrator-gitops
  labels:
    app-type: workflow
    app: yfassess
spec:
  destination:
    namespace: sonataflow-infra
    server: https://kubernetes.default.svc
  project: orchestrator-gitops
  source:
    path: ./kustomize/base
    repoURL: git@github.com:test-workflows/yfassess-gitops.git
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

making an argo application from the code repo smell like a hack, specially when tekton is for that.
can you explain that workaround and what made the tekton unusable in that case?}

[masayag]

@dmartinol pls correct me if I'm mistaken here.
We had a problem with creating the workflow's pipeline from a software template when the deploying cluster is behind VPN. See #24

Instead, a tekton pipeline template is added to the source workflow repository by the software template

That pipeline template is used by the github action to create a new pipeline run with the submitted commit, which triggers the build due to the argocd application that watches for changes for this source repository.

To summarize, the current process for the workflow repository:

1. Create a PR
2. Merge a PR
3. Github action creates and commit a tekton pipeline run
4. ArgoCD capture the new pipeline run and applies it on the cluster
5. The pipeline run builds the workflow image, generate resources, publish to the gitops repo...

We can explore alternatives to this process.

[dmartinol]

@masayag Probably we need step 0: after creating the software template, manually deploy the bootstrap application from the config repo, as explained in https://github.com/parodos-dev/onboarding-gitops/blob/main/bootstrap/README.md

making an argo application from the code repo smell like a hack, specially when tekton is for that.
can you explain that workaround and what made the tekton unusable in that case?}

@rgolangh tekton is unusable until someone creates a PipelineRun instance to run the required tasks. IIRC, we are now using the pull update model because we tried the push model with webhooks from GH to create it automatically, but this was discarded because of the VPN networking issues.

[dmartinol]

@rgolangh please take into account also the need to access private repos, for which I initially raised
RoadieHQ/roadie-backstage-plugins#1298