feature: Add deploy workflow

SFulpius commented 3 weeks ago

What type of PR is this?

kind/feature

What this PR does / why we need it:

This PR implements the deploy part of proposal 1. It adds a workflow that can be triggered by the workflow_dispatch event. The workflow apply flux manifests and wait for flux to deploy the project on the cluster. At this point everything is ready to start the benchmarks, which will be implemented in a future pull request. Finally it deletes the manifests and wait until the cluster state is clean.

Which issue(s) this PR fixes:

Fixes #99

Special notes for your reviewer (optional):

Right now the manifests for all three falco drivers are the same as there is only one kustomization file with all drivers in the repo. This should be changed once there is a way to run only one driver (#100).
The project is now deployed in the benchmark namespace. It was deployed in the falco namespace before. This way we can always use the same name when we interact with the namespace, instead of having one different namespace per project. The benchmark namespace still need to be created.
I could not run on the CI the part using kubectl as I do not have access to a kubeconfig file. I tested these manually on a local cluster.
I made the assumption that a secret named KUBECONFIG exists containing a kubeconfig that can be used to access the cluster.

rossf7 commented 3 weeks ago

Right now the manifests for all three falco drivers are the same as there is only one kustomization file with all drivers in the repo. This should be changed once there is a way to run only one driver (https://github.com/cncf-tags/green-reviews-tooling/issues/100).

Yes, I think we want separate manifests per driver. My plan for #100 is to have an overlay per driver. We can integrate this once those changes are ready.

The project is now deployed in the benchmark namespace. It was deployed in the falco namespace before. This way we can always use the same name when we interact with the namespace, instead of having one different namespace per project. The benchmark namespace still need to be created.

Agree on changing the name of the namespace. We can either create it permanently via Flux by adding it here https://github.com/cncf-tags/green-reviews-tooling/tree/main/clusters/base

Or if we are worried about leftover resources we could create it as part of the deploy step and delete after the flux manifest is deleted? For simplicity I would go for the first option for now.

I made the assumption that a secret named KUBECONFIG exists containing a kubeconfig that can be used to access the cluster.

Yes, will get this added.

SFulpius commented 2 weeks ago

@rossf7 I created the benchmark namespace and split the workflow into two jobs.

rossf7 commented 2 weeks ago

@SFulpius Another renaming nit 🙏

We use kebab-case for files so pls rename to modern-ebpf.yaml.

This will also align with the projects.json file

{
    "projects": [
        {
            "name": "falco",
            "organization": "falcosecurity",
            "sub_components": [
                "ebpf",
                "modern-ebpf",
                "kmod"
            ]
        }
    ]
}

rossf7 commented 2 weeks ago

Thank you @SFulpius! Great job getting this implemented 💚

cncf-tags / green-reviews-tooling