Skip to content

Support for "match releasing"#53

Draft
PeterJCLaw wants to merge 11 commits intomainfrom
match-release
Draft

Support for "match releasing"#53
PeterJCLaw wants to merge 11 commits intomainfrom
match-release

Conversation

@PeterJCLaw
Copy link
Owner

@PeterJCLaw PeterJCLaw commented Jan 18, 2026

This introduces the idea that a match needs to be "released" before it can actually run.

This does not change the schedule times, which are what remain published. Instead we adjust the idea of what the "current" match is and mark each match with a state (released, held or future).

This needs changes from other parts of the ecosystem to work and thus may warrant a major release number.

Related changes:

TODO (this PR):

  • add test coverage

TODO (general):

  • generalise deploy logic for use outside CLI
  • build a lineside UI

This implements the core logic around match states, though is
untested. There's no support here yet for making edits.
This is largely copied over from srcomp-http in order to centralise
the logic and enable easier changes.
While *mostly* we want this to be the current time, there are cases
where we want to freeze the current time for several requests.
This is particularly the case in srcomp-http for example.
This introduces (horror!) the idea of an "effective time" which
advances only as far as the next unreleased match's release threshold.
There isn't really any need for that to be the case, even if that's
the intended use-case. Certainly nothing about the logic actually
relies on that being the case.
Now that we have operational considerations on top of the schedule,
this would return a misleading view of the matches at a given time.

If it turns out that we need a view of the originally scheduled
matches at a given time we can reintroduce it, though with a clearer
name (likely `matches_scheduled_at`).
With how this is currently implenented (especially in the opt-out
case) there isn't really a way to have this validation. It's also
unclear whether or not this is useful.
Not strictly something we need, however since we validate our
minimum dependencies actually work this is needed for that to
pass.
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.

1 participant