-
Notifications
You must be signed in to change notification settings - Fork 14
Milestones V2 #318
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
Closed
Closed
Milestones V2 #318
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8b867f0
to
31e5f90
Compare
msaroufim
approved these changes
Jul 28, 2025
for some reason, these are not compatible with T4; which gives us a nice test-case/motivation for allowing the exclusion of certain GPUs from milestones
Coverage reportClick to see where and how coverage changed
This report was generated by python-coverage-comment-action |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a heavily modified/updated version of #291
It is rebased onto the libkernelbot changes, and uses a separate table to store milestone definitions as discussed.
The major design question that I'm not completely sure about is how to handle milestone runs.
In this version of the code, a
milestone_id
column is added to the runs table, and we set a constraint that enforces either submission or milestone id to be set. This is minimally invasive, but I wouldn't call it pretty. Contrary to what I first thought, though, it doesn't require any changes to existing queries. In order to match runs to leaderboards, we need to join on submission_id, so all milestone runs get filtered out automatically. A good sign for this approach?Alternatives could be to distinguish at the submission level (as in @PaliC 's original code), or to have two completely separate tables (claude says there is a postgres-specific extension that allows table inheritance, but i'm not really sure of the implications of this).
At this point, the implementation is fully functional, but could use some interface tweaks/improvements:
update-problems needs to become milestone-aware(implemented, but not really tested yet)