fix(CI): publish KubeArmorOperator Helm charts

[DelusionalOptimist]

Purpose of PR?:

Description:

• Moves KubeArmorOperator helm chart to deployments/helm so that it can be published by the chart releaser wf
• Changes PR/commit authors to github bot for automatically created PRs and commits.
• Changes branch from gh-pages to main.

Does this PR introduce a breaking change?
No

If the changes in this PR are manually verified, list down the scenarios covered::
Ran them on my own fork by creating a stable release.
Created PR: DelusionalOptimist#22
Published chart: DelusionalOptimist/charts@211e57b

Checklist:

• Bug fix. Fixes #
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• PR Title follows the convention of <type>(<scope>): <subject>
• Commit has unit tests
• Commit has integration tests

[daemon1024]

Can we also copy the README for helm? Since we are syncing the charts itself maybe syncing the README also makes sense?

[DelusionalOptimist]

Can we also copy the README for helm? Since we are syncing the charts itself maybe syncing the README also makes sense?

@daemon1024 The GH action that we are using only commits and pushes helm chart changes. So we'll have to update README manually or create a separate automated commit. WDYT?

[rksharma95]

KubeArmor/deployments/helm/templates/RBAC/bindings.yaml

Line 31 in f58a36b

namespace: kube-system

please include the fix to use release namespace here also with this PR itself.

[DelusionalOptimist]

@rksharma95 @daemon1024 I've added a commit which builds the operator with local paths for dependencies while taking care of docker build context. This will get us rid of the hassle of updating our packages upstream before we update the operator. PTAL.

[rksharma95]

@rksharma95 @daemon1024 I've added a commit which builds the operator with local paths for dependencies while taking care of docker build context. This will get us rid of the hassle of updating our packages upstream before we update the operator. PTAL.

KubeArmor/tree/main/deployments/get we need to add this path to test-operator and release-operator ci workflow.
should we merge controller-test and operator-test workflow and we can check for path which pkg got updated WDYT @DelusionalOptimist ?

[DelusionalOptimist]

KubeArmor/tree/main/deployments/get we need to add this path to test-operator and release-operator ci workflow.
should we merge controller-test and operator-test workflow and we can check for path which pkg got updated WDYT @DelusionalOptimist ?

@rksharma95 If I understand correctly, we'll have a common workflow which builds images for controller and operator based on the paths changed in PR and then run KubeArmor using operator.
We can do it at the repository level. A common CI workflow for PRs which will check all paths, build images as needed, push them to some temporary registry and run the ginkgo tests. No need to build image in all the runtime-specific workflows. It'll save us a lot of time.
But we can do this and a lot of other refactoring. If the operator-test and controller-test workflow merge is not urgent, I propose we should keep it as a part of the CI refactor in v0.12? What do you say?

[rksharma95]

But we can do this and a lot of other refactoring. If the operator-test and controller-test workflow merge is not urgent, I propose we should keep it as a part of the CI refactor in v0.12? What do you say?

let's target it in v0.12 🚀