-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Add heuristics for issue tracker #12703
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! We're almost there. Just a few comments. Most are minor, but I do think it matters we be robust about handling multiple components in the saved search.
Oh, and update the PR description....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two minor code suggestions and two doc suggestions.
Also, could you modify /.github/workflows/main.yml
so that it has a workflow_dispatch
trigger, so we can kick off this workflow from the GitHub UI when we need to? (It will also be a quick way of seeing this take effect after we merge!) It's just adding a line identical to this one
scripts/updateapilist.py
Outdated
|
||
# GENERIC_ISSUE_TRACKER_COMPONENT defines a generic component for issue tracker. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment will leave us/others puzzled in the future. Let's briefly expand why we care:
"This issue-tracker component is part of some saved searches for listing API-side issues. However, when we construct URLs for filing new issues (which in some cases we do by analyzing the query string for a saved search), we want to ensure we DON'T file a new issue against this generic component but against a more specific one."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed.
scripts/updateapilist.py
Outdated
for component_id in query_match: | ||
if component_id != GENERIC_ISSUE_TRACKER_COMPONENT: | ||
return component_id | ||
return None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be safe in case there's more than one non-generic component, what do you think of this?
for component_id in query_match: | |
if component_id != GENERIC_ISSUE_TRACKER_COMPONENT: | |
return component_id | |
return None | |
target_component = None | |
for component_id in query_match: | |
if component_id == GENERIC_ISSUE_TRACKER_COMPONENT: | |
continue | |
if target_component: | |
# We extracted two possible target components. We don't want to use the wrong one. | |
return None | |
target_component=component_id | |
return target_component |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed.
scripts/updateapilist.py
Outdated
f" - |PyPI-{client.distribution_name}|\n", | ||
f" - {client.release_level}\n", | ||
f" - |PyPI-{client.distribution_name}|\n", | ||
f" - `API Issues <{client.show_api_issues}>`_\n" if client.issue_tracker_component_id else " -\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be cleaner to reference that same object in the string and the conditional. Otherwise you're breaking encapsulation, knowing that if there's a component then the resulting string exists.
f" - `API Issues <{client.FOO}>`_\n" if client.FOO else " -\n",
And it might make sense to assign these values to local variables first so you don't call and run any getters repeatedly in these lines. (I don't know whether the interpreter can optimize that away; I would assume not.)
(Sorry, I meant to send this comment last night but I forgot to do the final click)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addressed.
_show_api_issues = client.show_api_issues | ||
_file_api_issue = client.file_api_issue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(No action needed--just a comment)
You could also memoize the two properties on the RHS. The complication is that for this application, you need two pieces of information for the memoization (as you implemented above), and that's because the cached value could be None
. In many applications, the memoized value is not None
, so the value None
can stand for "not yet cached". So I don't think it's worth pursuing here, because it adds two fields to the class, and this is certainly clear enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some cosmetic comments. Two of them are non-nit clarifications; please address. The others are nits; up to you.
Thank you so much for doing this! This looks like really solid code.
(Oh, and if you could remove the trailing whitespace from your lines [mostly from the empty lines], that would be a nice-to-have if it's easy to do. Otherwise don't worry about it.)
README.rst
Outdated
- |PyPI-google-cloud-access-approval| | ||
- | ||
- | ||
- `Client Library Issues <https://github.com/googleapis/google-cloud-python/issues>`_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking comment. Please feel free to file a bug as follow up work
For projects where we are creating issues directly in google-cloud-python we could update this link to point to template for filing an issue: For example, https://github.com/googleapis/google-cloud-python/issues/new?assignees=&labels=&projects=&template=bug_report.md
One benefit of this is that we can set the labels
parameter in the url which is empty by default.
For example, we could add the type: bug
label and api: access approval
label , using url encoding for the colon and space characters.
https://github.com/googleapis/google-cloud-python/issues/new?assignees=&labels=type%3A%20bug%2Capi%3A%20accessapproval&projects=&template=bug_report.md
As long as the priority remains unset, the bug will be considered un-triaged and will still appear in the un-triaged list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest we do this as a follow-up after we have the new issue templates set up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes #11147 🦕
Fixes #12679