feature: Add deploy workflow

[SFulpius]

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 ([ACTION] Modify flux resources for Falco to support pipeline #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]

@SFulpius Nice this is looking good. Will reply to your notes separately.

My main question is how will we add the run and report steps later?

I think we could do this by giving the workflow a more generic name like pipeline and having multiple jobs with deploy running first and a final job to delete the resources.

[rossf7]

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).

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]

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

[rossf7]

Thank you @SFulpius! Just one nit pls rename the file to benchmark-namespace.yaml

Otherwise LGTM! 🚀

[rossf7]

@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]

Thank you @SFulpius! Great job getting this implemented 💚