-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experimental support for argocd action to deploy the argo app #60
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Roy Golan <rgolan@redhat.com>
action: argocd:create-resources | ||
input: | ||
appName: ${{ parameters.component_id }}-bootstrap | ||
argoInstance: main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ?
@rgolangh when this one verified, it closes https://issues.redhat.com/browse/FLPATH-1322 |
name: Create ArgoCD Resources | ||
action: argocd:create-resources | ||
input: | ||
appName: ${{ parameters.component_id }}-bootstrap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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:
- Create a PR
- Merge a PR
- Github action creates and commit a tekton pipeline run
- ArgoCD capture the new pipeline run and applies it on the cluster
- The pipeline run builds the workflow image, generate resources, publish to the gitops repo...
We can explore alternatives to this process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
@rgolangh please take into account also the need to access private repos, for which I initially raised |
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