Add codeowners tooling to this repository

[mx-psi]

We have some tooling on the opentelemetry-collector-contrib that allows us to automate some actions related to codeowners:

• ping-codeowners-prs
• ping-codeowners-on-new-issue
• ping-codeowners-issues.yml
• add-codeowners-to-pr

We can add the tooling one by one. Some of these may need additional tooling (more issue templates?):

• Ping code owners on PRs for a component
• Ping code owners on new issues
• Ping code owners on existing issues
• Add code owners as reviewers in a PR

[mowies]

i'd like to work on this :)

[mowies]

@mx-psi so after a quick review of the 4 links above, I noticed that probably only the issue related things will really work on this repo. That's because the codeowners file is not set up as granular here compared to the contrib repo so the PR related workflows, that would ping codeowners for specific folders would just generate a ton of notifications for the collector maintainers.

Update: the * is not specifically respected by the automations so if a specific component is not found in the codeowners file, no notification will be sent and the * will be ignored

[mx-psi]

@mowies That's fair. There will be a long transition period in which a lot of things do not have a codeowner. I think we should ignore the * line and only trigger automation if we are on a more specific line.

I am working on a PR that should be ready on Wednesday adding more specific codeowners, maybe after that is ready it's a good time to see how this would work in practice

[mowies]

The automations only look for specific labels as components anyways, so they already ignore the * case.

[mowies]

For some of the automations to work, I would also need to adjust the existing issue templates and probably mostly exchange them for the ones from the contrib repo. Should I add that to this PR or rather create a separate one?

[mx-psi]

The automations only look for specific labels as components anyways, so they already ignore the * case.

Ah, goes to show how little I know about this 😅 I don't understand the notifications issue you mention above. Could you explain with an example where we would get a lot of notifications?

Should I add that to this PR or rather create a separate one?

Let's create a separate one for this

[mowies]

I thought at first, that the * in the codeowners file of this repo would be respected by the automations and since that's (almost) the only entry in the file, that would trigger as a fallback for all components that are not specifically listed, but that's not actually the case after digging a little deeper. Instead, if the specific component is not found in the codeowners file, nobody will get notified. So that's good I guess in terms of spam 😅

[mx-psi]

Makes sense! Then yeah, the tooling will not be super useful until we have a more fleshed out list of codeowners, but it will be good as a start.

[mowies]

Yeah I think it's still good to have them in place. As soon as the issue templates are updated, we at least get labels for components, which is already something 😄
And since no notification spam will occur, I can also go ahead and add the PR related automations as well I think.

[mowies]

some more ideas around this that i will extend over the course of implementing this:

• i think a few tools and scripts could be moved to a central repo like https://github.com/open-telemetry/opentelemetry-go-build-tools so that they can be reused and don't need to be copy/pasted all over the place (i'm copying lots of things from contrib into core right now. for example pipelines, githubgen tool)
• most of the automations that i'm adding now, are written in bash. i think it would make sense to rewrite those in a more accessible language like typescript or so while moving them to a central location
• the githubgen tool really needs an exclusion list so that things like the test file here don't surface as errors (user some that exists but is completely unrelated to this and otel in general)
• ...

EDIT:
filed an issue to move githubgen to the go-build-tools repo: open-telemetry/opentelemetry-collector-contrib#36691

[dmathieu]

i think a few tools and scripts could be moved to a central repo

otel-go-contrib is also copying some of the scripts from collector-contrib, so that repository would be interested in that too.