Add CODEOWNERS file to o11y rocks

[sed-i]

• I have signed the CLA?
• I am following the CONTRIBUTING guidelines

Ping the @canonical/rocks team.

---

Description

This PR adds CODEOWNERS files to observability rocks.
This is helpful to avoid creating our own branches with new PRs for fixing rock builds. The most common scenario is adding a line to trivyignore.

Related issues

Here are some examples to PRs I had to create because I couldn't push into existing PRs:

• Add otelcol 0.145.0 #768
• Add mimir 2.7.14 #767
• Add alertmanager v0.31.1 #765

[alesancor1]

Hi, thanks for this.

Please help me understand the issue here.

This is helpful to avoid creating our own branches with new PRs for fixing rock builds. The most common scenario is adding a line to trivyignore.

^ Isn't this how it is supposed to be?

Here are some examples to PRs I had to create because I couldn't push into existing PRs

^ This doesn't sound like the upstream OCI-Factory (here) is the place to have this fixed, does it?

Could you please explain what is it that you are trying to do more specifically?

[sed-i]

So the issue is:

1. We have a PR created automatically by CI when we merge a rock. This is great.
2. On oci-factory side, the CI fails for CVE check.
3. Now I cannot push into the PR that was created by CI - I have to create a branch in my own fork, and open a new PR, and comment on the original one that it is superseded.

[alesancor1]

So the issue is:

1. We have a PR created automatically by CI when we merge a rock. This is great.

2. On oci-factory side, the CI fails for CVE check.

3. Now I cannot push into the PR that was created by CI - I have to create a branch in my own fork, and open a new PR, and comment on the original one that it is superseded.

Afaiu, this issue is specific to how your team integrates with OCI-Factory. Different teams contributing to the OCI-Factory may have varying processes, and the upstream repository operates under its own established constraints and governance. For that reason, it may not be appropiate to adjust the upstream workflow to accomodate a particular use case.

Having said that, most of the CI/CD issues you typically encounter in the OCI-Factory PRs -including CVEs detection- are coming from reusable workflows (Build.yaml / Test.yaml) which you can incorporate to your rocks pipeline (e.g. using the rocks-template) to ensure that OCI-Factory checks will pass even before creating the PR.

But if you still need to push to those PRs made by the Noctua bot, shouldn't it be enough to modify its fork repository settings to allow pushes from observability? Maybe I'm missing something here.

[zhijie-yang]

The easiest way for you would be onboarding your noctua bot to the OCI Factory, and use the CLI client to trigger the Image workflows, such that you don't even need to open a PR or make persist changes to the image.yaml file. We'll add support to specify ignored-vulnerabilities in the CLI client when triggering the workflow. With this, you can completely get rid of using PRs to build images.

The CLI client should have a easy integration to your existing workflows. I believe the IAM and data platform teams are already using this pattern.