all: adding codeowners

[viktor-f]

Warning

This is a public repository, ensure not to disclose:

• personal data beyond what is necessary for interacting with this pull request, nor
• business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

• kind/feature
• kind/improvement
• kind/deprecation
• kind/documentation
• kind/clean-up
• kind/bug
• kind/other

Optional: Mark one or more of the following that are applicable:

Important

Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

• kind/admin-change
• kind/dev-change
• kind/security
• kind/adr

What does this PR do / why do we need this PR?

This is a first draft of adding codeowners to this repo.
There are probably some things that could be changed or something that was missed. Please at least look at your goto areas to see that they seem sensible. We would also appreciate comments on the skipped files to see if they should be given to any area.

• Fixes #

Information to reviewers

Checklist

• Proper commit message prefix on all commits
• Change checks:
  • The change is transparent
  • The change is disruptive
  • The change requires no migration steps
  • The change requires migration steps
  • The change upgrades CRDs
  • The change updates the config and the schema
• Documentation checks:
  • The public documentation required no updates
  • The public documentation required an update - [link to change](set-me)
• Metrics checks:
  • The metrics are still exposed and present in Grafana after the change
  • The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
  • The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)
• Logs checks:
  • The logs do not show any errors after the change
• Pod Security Policy checks:
  • Any changed pod is covered by Pod Security Admission
  • Any changed pod is covered by Gatekeeper Pod Security Policies
  • The change does not cause any pods to be blocked by Pod Security Admission or Policies
• Network Policy checks:
  • Any changed pod is covered by Network Policies
  • The change does not cause any dropped packets in the NetworkPolicy Dashboard
• Audit checks:
  • The change does not cause any unnecessary Kubernetes audit events
  • The change requires changes to Kubernetes audit policy
• Falco checks:
  • The change does not cause any alerts to be generated by Falco
• Bug checks:
  • The bug fix is covered by regression tests

[AlbinB97]

Shouldnt this be @elastisys/goto-scripts ?

[Ajarmar]

It seems there are a lot of errors in the CODEOWNERS file, but I imagine it is something sysadmin needs to fix? Specifically, teams not having write access to the repo/not being publicly visible, and team names with / in them look like they don't work correctly.

[Ajarmar]

Should be continuous delivery goto?

[Ajarmar]

Suggested change

	/helmfile.d/stacks/velero.yaml @ elastisys/security-goto
	/helmfile.d/stacks/velero.yaml @elastisys/goto-security

[Ajarmar]

Suggested change

	/helmfile.d/charts/habor/ @elastisys/goto-container-registry
	/helmfile.d/charts/harbor/ @elastisys/goto-container-registry

[Ajarmar]

Suggested change

	/helmfile.d/charts/tekton-pipelines/ @elastisys/goto-continous-delivery
	/helmfile.d/charts/tekton-pipelines/ @elastisys/goto-continuous-delivery

You spelled it the way the team is spelled so it was technically correct, but I'd love to get this typo fixed in the team name. @Xartos @robinelastisys

[Ajarmar]

What's the motivation for this one?

[viktor-f]

I added that goto for .github/ and then thought that this was an adjacent file. But the reasoning was not very concrete 😅
If you want to remove or change it then I'm very open for suggestions.

[Ajarmar]

I think it doesn't really apply to any goto area, probably makes most sense to remove it

[Ajarmar]

Suggested change

	/helmfile.d/stacks/thanos.yaml @elastisys/monitoring-stack
	/helmfile.d/stacks/thanos.yaml @elastisys/goto-monitoring-stack

[Ajarmar]

Suggested change

	/helmfile.d/stacks/fluentd.yaml @elatisys/logging-stack-goto
	/helmfile.d/stacks/fluentd.yaml @elatisys/goto-logging-stack

[Xartos]

This doesn't seem to be allowed. Or is it just a bad parser?

Also, do we want to have sub teams with this instead of having it as a parent group? Then the goto-pipeline would automatically include all in all the subteams

[Xartos]

Suggested change

	/bin/ @scripts-goto
	/bin/ @elastisys/goto-scripts

[Xartos]

These doesn't seem to be public enough 🤔

[Xartos]

Do we need to have this if we have them for /scripts/*?

[viktor-f]

Yes, as far as I understand. This is from the codeowner documentation:

The docs/* pattern will match files like
docs/getting-started.md but not further nested files like
docs/build-app/troubleshooting.md.
docs/* [email protected]

[Zash]

The documentation says it follows .gitignore syntax, and the .gitignore pattern format documentation states:

A trailing "/**" matches everything inside. For example, "abc/**"
matches all files inside directory "abc", relative to the location of
the .gitignore file, with infinite depth.

So in theory this should do (replacing all the rules with the prefix /scripts/):

Suggested change

	/scripts/S3/ @elastisys/goto-scripts
	/scripts/** @elastisys/goto-scripts

[Xartos]

Could this be changed to

Suggested change

	/scripts/* @elastisys/goto-scripts
	/scripts/ @elastisys/goto-scripts

[viktor-f]

It will give a bit of a different meaning, check my comment to your previous comment.

[aarnq]

You should be able to set us for /scripts/ before other entries in script, and the more specific ones will override the generic one.

From the docs:

# In this example, @octocat owns any file in the `/apps`
# directory in the root of your repository except for the `/apps/github`
# subdirectory, as this subdirectory has its own owner @doctocat
/apps/ @octocat
/apps/github @doctocat

[Xartos]

We should probably rename this folder, or create a subfolder

Suggested change

	/scripts/restore/ @elastisys/goto-container-registry
	/scripts/restore/harbor/ @elastisys/goto-container-registry

[viktor-f]

Yeah I was thinking about that as well. I was just not sure if I wanted to do that in this PR and if that had implications on other things as well.

[viktor-f]

As people have noted there seem to be issues with the goto teams not being publicly visible and not being able to have / in the name. I was too quick to create the PR and didn't check the errors in github.

@Xartos or @robinelastisys
Could you look into making them public and renaming "goto-ingress/auth" to "goto-ingress-auth" and "goto-pipeline/qa/release" to "goto-pipeline-qa-release" (or something similar)?

[aarnq]

Is this chart even used nowadays? 🤔

[aarnq]

Suggested change

	/scripts/report/ @elastisys/goto-security
	/scripts/report/ @elastisys/goto-pipeline-qa-release

[Xartos]

Could you look into making them public

As far as I can see they are as public as they can be 🤔 @robinelastisys Do you know some other way of making them even more public

[aarnq]

Could you look into making them public

As far as I can see they are as public as they can be 🤔 @robinelastisys Do you know some other way of making them even more public

Maybe:

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-syntax
Users and teams must have explicit write access to the repository, even if the team's members already have access.

[Xartos]

Could you look into making them public

As far as I can see they are as public as they can be 🤔 @robinelastisys Do you know some other way of making them even more public

Maybe:

docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-syntax
Users and teams must have explicit write access to the repository, even if the team's members already have access.

Yea, that's probably correct. But that feels like a bunch of work that I don't want to manage manually. I'll take a look if this can be managed in a better way. We will probably want to manage the teams in a better way anyway so I think that is a good opportunity to fix that

[simonklb]

This should be owned by goto-scripts IMO as it declares the dependencies for running the scripts in /bin.

[simonklb]

QA?

[simonklb]

goto-security?

[simonklb]

I wonder if this should be maintained by public docs?