The steps you should follow would be, read the README.md
in the following order:
- pipeline-instruction
- gitea
- droneCI
- argocd
- owasp-zap (draft)
Our pipeline runs in Kubernetes.
- Code pipeline (Source code): Opens PR for feature branch -> master branch Secret detection, static analysis and image scanning will run in the pipeline. If it passes all the tests, update and push image into the image registry. If fails, break the pipeline.
- GitOps pipeline (Config manifest): Opens PR for the new release manifest.
kubelint runs towards the manifests config files. If it passes all the tests, developer can merge the PR, otherwise the pipeline blocks the PR from merging.
ArgoCD is monitoring the GitOps repo. So once the PR gets merged into main branch, ArgoCD will realise the change since the Kubernetes cluster’s manifest and GitOps manifest are different.
ArgoCD will update and deploy with new GitOps Repo’s manifest. By having argocd app wait APPNAME
step in the pipeline, it won't go to the next step until the sync is done, and once the sync is done (aka. ArgoCD deployed on Kubernetes Dev Cluster) fuzzer runs toward that live server.
(Note that fuzzer needs (documentation, openAPI) && (Active server) )
kind: pipeline
type: docker
name: default
steps:
- name: cd
image: argoproj/argocd-cli
commands:
- argocd app wait APPNAME
- name: fuzzer
image: owasp/zap2docker-stable
commands:
- Some commands to run the fuzzer towards the active target server
-> Successful: Pipeline will send webhook to Gitea to notify the developer that the dynamic testing was successful.
-> Failure: Breaks the pipeline
Our demo pipeline only covers the dev cluster, but ideally in the real world, for the production cluster we will open a new PR in order to push code from dev cluster to prod cluster Kubernetes.