Automate org.yaml generation

[zuc]

Motivation

Current peribolos file is being manually curated. This is of course prone to human error.

Feature

Generate org.yaml automatically.

Alternatives

N/A

Additional context

This should be done after #176 is completed.

[zuc]

/cc @leogr @maxgio92 @jasondellaluce
/assign @zuc

[zuc]

Note to self: current maintainers/repositories yaml files purposely exclude some data that is actually needed by peribolos (eg. archived repos).

[leogr]

Note to self: current maintainers/repositories yaml files purposely exclude some data that is actually needed by peribolos (eg. archived repos).

AFAIK, one must first archive the repository using the GH UI. Otherwise archived: true in peribolos won't work. Should we get that information from the GH API? 🤔

Also, the only path to invite a new member to the org is by adding it to org.yaml. I guess that will remain a change that has to be manually applied to org.yaml, right?

[zuc]

Fetching repo info from GH APIs to feed a file that is supposed to manage/update the same repo(s) doesn't seem a good path to me.

I still have to draw a plan on this but what I'd like to do is:

1. Have a single source of truth about our repos in a general purpose, machine-readable format (that could be the existing https://github.com/falcosecurity/evolution/blob/main/repositories.yaml file which needs to be enriched with some data). This file will be manually curated to represent the desired state of the repos org-wide.
2. For each repo listed in the above-mentioned file, fetch OWNERS file content; that could be done either using https://github.com/leodido/maintainers-generator or through a custom util.
3. Have all the automation processes consume those files to perform all other ops (eg. generate org.yaml, generate markdown(s), ...).

[leogr]

Somehow related, IMO 👇
#198

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

we still want this

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale
/help

[poiana]

@leogr:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/remove-lifecycle stale
/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[maxgio92]

I have a question about this: why not org.yaml Peribolos config could be the source of truth about repositories too?

Edit: somehow related falcosecurity/test-infra#777

[leogr]

I have a question about this: why not org.yaml Peribolos config could be the source of truth about repositories too?

Edit: somehow related falcosecurity/test-infra#777

Hey @maxgio92

Good question!

Our source of truth is the OWNERS files that are spread across all repos and get modified using PRs (required for voting).

Furthermore, our governance has some logic that would not be possible to implement with only the data hosted by org.yaml.

For example, the repositories.yaml is the source of truth for core repository (since org.yaml can't host this data). Being maintainers of a core repository implies being part of the core-maintainers team in org.yaml (the vice-versa does not apply).

So it's more convenient to generate org.yaml starting from OWNERS files and other input files (like repositories.yaml) rather than the opposite. In some cases, like the examples above, it's the only possible way.

Hoping this will help to clarify.

[maxgio92]

Sure, thank you @leogr.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[poiana]

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

[poiana]

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[leogr]

/remove-lifecycle rotten
/reopen

[poiana]

@leogr: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale