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

TypeError: %d format: a number is required, not NoneType #7

Closed
Titaniumtown opened this issue Aug 24, 2020 · 1 comment
Closed

TypeError: %d format: a number is required, not NoneType #7

Titaniumtown opened this issue Aug 24, 2020 · 1 comment

Comments

@Titaniumtown
Copy link

running this command will use 27 requests to the github api
200
Yatopia Build Script
found workflow 640688
200
Traceback (most recent call last):
  File "main.py", line 38, in <module>
    artifact_dict[BRANCH]["java-8"] = get_latest_artifact_url(WORKFLOW_NAME, WORKFLOW_EVENT, ARTIFACT_NAME, OWNER, REPO, BRANCH)
  File "/run/media/simon/778dacfe-6c5b-4d99-aaec-9149f943614d/home/simon/Desktop/code/yatopia-autoupdate/artifact_lib.py", line 72, in get_latest_artifact_url
    print("found workflow_run_id %d" % workflow_run_id)
TypeError: %d format: a number is required, not NoneType
@JayFoxRox
Copy link
Owner

yatopia-autoupdate/artifact_lib.py", line 72

That code is not part of this repository. It's part of "sort-of rejected" PR #5.
It's also a minor issue because #4 prevents any use of these functions, so fixing minor bugs is a non-goal.

However, the same issue exists in:

workflow_run_id = get_latest_workflow_run_id(workflow_id, worfklow_event)
print("found workflow_run_id %d" % workflow_run_id)

- but it's not a real issue in my opinion.

It simply means that no matching workflow-run ID was found via get_latest_workflow_run_id:

return None #FIXME: Exception

So this is something you can explicitly check where you use it, or do what the comment suggests and throw a meaningful exception (depending on what is the more Python-way of doing / personal preference).

For __main__ in main.py this error is fine (in my opinion), because it's a lightweight sample script.
It's lacking all sorts of error checking (also see #3).
When running on a server it would likely run with a watchdog so it could be restarted.

For other uses, as a ugly catch-all solution, you could simply wrap the entire use of these functions in try / except blocks (which is probably informative enough for most use-cases).


While we could keep this open, it's better to minimize the number of issues, and freeze development until #4 is solved.
Issue #3 already documents this issue in a more generic way, too.

Closed.

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

No branches or pull requests

2 participants