calculate PROPOSED and PLANNED project stages #192
Conversation
tools/ack-discover/controller.py
Outdated
|
|
||
| project_stage = project_stages.NONE | ||
| maintenance_phase = maintenance_phases.NONE | ||
| # If there is no source code repository yet for the controller, check |
There was a problem hiding this comment.
nit: this reads a little weird because the call to get_repo happens after this logic.
It seems like we have to set gh_issue_url and project_stage regardless of whether the repo exists today or not (to pass to Controller constructor). If that's true, I think it'd be clearer to update the comment to omit line 66
tools/ack-discover/controller.py
Outdated
| global _sc_proj | ||
| ack_org = gh.get_organization("aws-controllers-k8s") | ||
| community_repo = ack_org.get_repo("community") | ||
| writer.debug(f"[controller.get_service_controller_project] finding service controller Github Projectoking up project ...") |
There was a problem hiding this comment.
darn kids Projectoking on my lawn
There was a problem hiding this comment.
I'm pretty sure this is illegal in some states
| # The GH issues with label "Service Controller" all have the same title | ||
| # pattern: "<Service Name> service controller" |
There was a problem hiding this comment.
This feels like a big assumption. Will someone be going through and updating each of the service controller requests to match this?
There was a problem hiding this comment.
Not sure what else we can do, unfortunately... we can't really lock down the Issue title template :)
tools/ack-discover/controller.py
Outdated
| @@ -133,3 +157,70 @@ def get_runtime_and_aws_sdk_version(writer, repo, image_version): | |||
| # proper Git tags for releases... | |||
| pass | |||
| return runtime_version, aws_sdk_version | |||
|
|
|||
|
|
|||
| def get_github_issue(writer, gh, service): | |||
There was a problem hiding this comment.
nit: Perhaps a more specific name?
| def get_github_issue(writer, gh, service): | |
| def get_controller_request_issue(writer, gh, service): |
tools/ack-discover/controller.py
Outdated
| global _sc_proj | ||
| ack_org = gh.get_organization("aws-controllers-k8s") | ||
| community_repo = ack_org.get_repo("community") | ||
| writer.debug(f"[controller.get_service_controller_project] finding service controller Github Projectoking up project ...") |
There was a problem hiding this comment.
I'm pretty sure this is illegal in some states
Adds code to the ack-discover utility that calculates whether an AWS service is in the PROPOSED or PLANNED project stage. To determine the PROPOSED services, we look for a Github Issue with the "Service Controller" label and a title matching either the abbreviated or full service name. To determine the PLANNED services, we check to see if the Github Issue for a PROPOSED service is in the "Planned" Github ProjectColumn of the "Service Controller Release Roadmap" Github Project in the community repo. Signed-off-by: Jay Pipes <[email protected]>
| source_repo_url=None, | ||
| image_repo=None, | ||
| chart_repo=None, | ||
| gh_issue_url=gh_issue_url, | ||
| ) | ||
| result[service_package_name] = controller |
There was a problem hiding this comment.
For the case of EC2, would the current logic skip creating a controller for EC2 VPC issue? Or does services.items() contain an entry for both EC2 and EC2 VPC ?
There was a problem hiding this comment.
good question... in the case of EC2, we already have a controller so the service record's project phase is set to RELEASED. But for other services where we have multiple GH issues we will need to manually handle those I think.
There was a problem hiding this comment.
But for other services where we have multiple GH issues we will need to manually handle those I think.
I don't quite understand why services have multiple GH issues labeled Service Controller if the intent is each of these map to a single repo (or a single service API in aws-sdk). Ex EC2:
[Brainstorm] This code could be a good opportunity to "enforce" GH issue structure in that it expects 1 repo per Service Controller GH issue. We can consolidate existing issues today and since "services" is a known list with infrequent updates we can create all GH issues ahead of time for each service aligning with the expected format.
There was a problem hiding this comment.
@brycahta agreed, we could definitely take the opportunity to clean up our GH issues and standardize the service controller release roadmap project. For this particular PR, though, it's solving the initial problem at hand, which is to properly list PROPOSED and PLANNED project stages for specific services. This is important because I'm trying to replace the hand-edited services matrix with a table that is generated from the data produced by the ack-discover tool...
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: A-Hilaly, brycahta, jaypipes, RedbackThomson, vijtrip2 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Adds code to the ack-discover utility that calculates whether an AWS
service is in the PROPOSED or PLANNED project stage.
To determine the PROPOSED services, we look for a Github Issue with the
"Service Controller" label and a title matching either the abbreviated
or full service name.
To determine the PLANNED services, we check to see if the Github Issue
for a PROPOSED service is in the "Planned" Github ProjectColumn of the
"Service Controller Release Roadmap" Github Project in the community
repo.
Signed-off-by: Jay Pipes [email protected]
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.