-
Notifications
You must be signed in to change notification settings - Fork 3
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
BUG: fix parsing upload time #9
BUG: fix parsing upload time #9
Conversation
abde75d
to
e7d28b9
Compare
Thanks @neutrinoceros I will let @astrofrog or @ConorMacBride look over this as they understand it unlike me! |
I don't understand the failure but doesn't seem related?
Thanks for the quick fix! Hopefully it can be merged soon. If I have to wait a while to be able to upload a nightly wheel again, I might take Brigitta's suggestion to try out the Scientific Python workflow (xref #7). So please let me know if you are unable to get to this by the end of the week. Thanks! |
p.s. I wonder if there is a better way to future-proof in case the server changes the time formatting again. |
Thanks @neutrinoceros! As @pllim suggests it would be good to future-proof the parsing, but we can decide that in a different PR so we get the fix out now. One option would be to use the dateutil package to parse without specifying a format. Another would be to use regex to extract just a date ( |
It is only one specific wheel build that has the different time format ( The test failures in this PR are due to PRs not having access to secrets. |
I tend to prefer solutions that don't require new dependencies so if a regexp suffices, I can craft a more general solution tomorrow ! |
Moment of truth is approaching... https://github.com/astropy/astropy/actions/runs/7979290389 |
dev483 uploaded successfully. Thanks, all! |
This adresses an issue noticed downstream at astropy/astropy#16076, where a crash would occur when cleaning old wheels as the upload time stamp wouldn't match the expected format.
I have limited understanding of everything that's going on here so this might not be the correct approach, but it seemed simple enough. I've assumed that both the old and new timestamp format could still be in use so I wouldn't break backward compatibility, but maybe that's not important ?