Skip to content
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

Promote add_project_values() error logging from DEBUG to INFO #267

Merged
merged 1 commit into from
Dec 11, 2024

Conversation

webbnh
Copy link
Collaborator

@webbnh webbnh commented Dec 11, 2024

This PR follows #263 and #247: it's not evident, yet, why the story point values aren't being updated. There is some evidence that the attempt to fetch them from the GitHub Project is failing, but these failures aren't included in the log; so this PR promotes the logging in add_project_values() from DEBUG to INFO so that the log will show when there are errors accessing the GitHub Project.

This PR also slightly refactors add_project_values(), removing the nested levels of indentation by simply return'ing at the points where we determine that we cannot or will not update the GH project values. (I suggest suppressing whitespace differences when reviewing the changes.)

Copy link
Member

@ralphbean ralphbean left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

(nit: the diff is 99% about the refactor while the PR and commit suggests it is only about a logging change.)

@ralphbean ralphbean merged commit b9069c6 into main Dec 11, 2024
6 checks passed
@ralphbean ralphbean deleted the add_project_values-logging branch December 11, 2024 15:30
@webbnh
Copy link
Collaborator Author

webbnh commented Dec 11, 2024

the diff is 99% about the refactor while the PR

If you suppress the whitespace changes, then it's more like 62.5%, but I take your point. 🙂

commit suggests it is only about a logging change.

If you're looking here on the website, you have to click on the ellipsis to see the whole log message (it all shows here, though).

Still, the commit was motivated by the logging change which should be the only visible/functional change in the behavior. So, I put the important stuff in the first 72 characters, and left the rest to the next line of the commit log message (and, yeah, Git and related tools treat the first line as a summary and tend to elide the rest of the log).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants