Currently, everytime the verify job is run, API calls are made
to github to fetch kubernetes release information since verify
calls generate first.
The issue with this is that everytime this runs in the CI, eventhough
we only generate annual reports when ANNUAL_REPORT env is set, the
API calls are made and if they are rate limited (since we don't use
a token here), the job will fail without a legitamate reason.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
specifically:
- only sigs+committees can have subprojects
- subprojects need at least one owners entry
- owners should be raw github links
I think the last one could/should change, but:
- I'm about to auto-generate links assuming this format, so I want to
verify I can assume all owners are in this format
- I am not quite sure if we should treat sigs.yaml as public api and
give notice/deprecation for field changes
- Add LeadershipGroup#Owners() which returns a sorted and de-duped
list of owners ([]Person) for this LeadershipGroup by combining
Chairs and TechnicalLeads
- The function is used in generator/aliases.tmpl
- Update OWNERS_ALIASES with the new results
If we end up specifying the company for emeritus leads, we could end
up stale information. Moreover, we don't gain any specific value
from company info of emeritus leads.
Demonstrating this could be done, not going to enforce it for now.
There are also a number of these conventions that could probably
just be auto-generated.
The following formatting is enforced:
- Consistent identation of 2 spaces
- Keys are sorted by order of struct fields
- Lists are sorted by struct-dependent keys
- Comments are stripped
I had hopes of using yaml.Node to preserve comments, but found no
obvious way to marshal from struct to Node, meaning all data
manipulation had to be done against Nodes. This loses us all of the
benefits of using a struct: types, known fields, field order.
Given that there aren't many comments in sigs.yaml to begin with, I'm
erring on the side of dropping support for them.
Demonstrate by adding slack channels for sig-testing subprojects
that already have their own slack channels
Add a GitHub team related to conformance to sig-arch's conformance
definition subproject
GitHub teams as implemented now are very kubernetes-org centric,
I'm not trying to change that here, would suggest a followup
change to allow for the use of github teams in other orgs
(like kubernetes-sigs)
A subproject is a one-to-many mapping of a name to a list of
OWNERS urls. This allows for a subproject to be a single repo (eg:
helm), or a subproject to be a list of multiple subdirectories across
one or more repos (eg: workloads api)
SIG meetings dedicated to a single subproject moved down to subproject
meetings
Automatic merge from submit-queue. .
Update generator to use WHAT variable
Having to set two different variables is confusing. Changed this to look at the `WHAT` envvar and match on a suffix.
Fixes#1126.
cc: @jamiehannaford