Proto commits in hex539/scoreboard

These 26 commits are when the Protocol Buffers files have changed:

2019-04-29

Pass "--contest {id}" to resolve one in particular Eg. the following will resolve different contests: --url https://nwerc-judge.gehack.nl --contest practice --url https://nwerc-judge.gehack.nl --contest nwerc18 Default behaviour is to pick the first one in the array. If a contest ID is given that is nonexistent on the server, there will be no attempt to fall back to an existing one. If the contest ID is not known, it can be left out. Future work: give a nice console menu or GUI to choose what contest to resolve if it is ambiguous.

The documentation is generated from this commit.

2019-03-16

Annotate why enum fields do not have a json_name This is a bug (/feature request) in protobuf as specifying a custom name for json enum fields is clearly useful if the name is not representable as a label in protobuf syntax. Upstream issue: https://github.com/protocolbuffers/protobuf/issues/4328

2018-12-25

Support optionals in DomJudgeV3 with wrappers Tested on a variety of sites. Hopefully addresses #2. The only difference I found when test-importing contests is that now the Contest struct (correctly) doesn't include a scoreboard_freeze_duration if a freeze_time is not set in the original DomJudgeV3 contest. This means that scoreboards without a freeze will just go straight to the final scoreboard for resolution, as they should.

2018-12-16

Implement conversion of event feed back to JSON.

2018-12-15

First steps at parsing the event-feed endpoint Can eventually be paired with the hacked "event_id" field from the scoreboard endpoint to jump into the right position in a contest. Not yet sure that this is necessarily the best idea for a live scoreboard specifically -- in this case it might be safest to just re-pull the /scoreboard endpoint whenever something interesting happens in the event feed, to avoid getting confused if eg. the active contest changes.

2018-11-11

Add Scoreboard to clics_v1 proto

2018-04-04

Domjudge APIv3 affil_id is "affilid" not "affilId" Because sure why not

Simplify proto BUILD rules for android target

2018-01-29

Restructure generic API for more shared code Everything is using ContestDownloader now, and the only thing not using ContestConfig is the android app (and that only because it is currently reading contests directly from its assets directory for reasons of speedier development). Domjudg3 and Clics APIs move under a common //api prefix since very little code should be using them directly.

2018-01-21

Step #1 towards making URL easy to enter correctly By auto-detecting based on a set of common patterns from typical installations of domjudge at various times. For the moment, any api matching the following pattern should be picked up: https?://contest.example.com/(domjudge/)?(api/(v3/)?)? For example running the console tool with... run scoreboards/console --url https://domjudge.bath.ac.uk resolver ...now works whereas before the API version and exact url (ending in domjudge/api or domjudge/api/v3 for clics or domjudge3 respectively) would have been needed too. The official format is preferred if there's a choice, and detected by seeing if the API returns anything for /groups, or /categories, or both. Ugly details are returned in a ContestConfig.Source protobuf which will be saved to disk in future and used for resuming a scoreboard later, but at the moment all the data is unceremoniously pulled out straight away and not checked again.

2018-01-18

Beginning of a python script to replay contests This just dumps out the entire contest in its final state at the moment without applying any changes. The timestamp and duration elements are hacked into the right shape by messing around with some internal structures from the protobuf json formatter. Once it's working it should be handy for testing live scoreboards with running contests, since that has to work quite differently to the resolver which only has to download the final state once and then it's good to go. An event feed might be necessary for this since it's the only kind of long-polling the official API seems to have, and just polling the scoreboard endpoint every 20 seconds isn't very nice (visually or network-ily) At the moment it is possible to set DOMJUDGE_CONTEST_API_IN_ROOT in ClicsProto to true and download the contest proto, which comes out identical to the one fed into this script.

Rejigger WORKSPACE to support python proto targets

2018-01-17

Replace the pubref protobuf rules with real ones

2018-01-11

Implement support for CLICS api Involved a large number of other changes to make it work. The API is not as abstract as it was before but over time it should evolve back into something that doesn't rely on a specific encoding of the data for internal behaviour. Of special note: replaced the basic scoreboard rank updater with one based on a SplayList (really more of a SplaySet due to not designing the interface very well, which is another thing to fix) so that rank updates are O(logN). This makes the initial phase of preparing the resolver faster for really large contests like NWERC 2017, since it involves submitting and re-ranking ~1250 times.

2018-01-07

Take Category sortOrder into account on scoreboard This orders teams in the scoreboard by Category.getSortOrder() instead of Category.getId().

2018-01-06

Step one toward using judgement_types for scoring Added a mapping from judging outcome to judgement type. This mapping doesn't seem to be presented properly by the API so for the moment this is guessed using a DefaultJudgementTypes class. Also added a User which is useful because of its being able to hold a list of User.Role[] which should be printed out to the requester in a warning message if they try to access something they're not allowed to see. Related to this, some of the endpoints necessary to download the whole contest state are behind User.Role.jury or above, so all of the HTTP request logic changed to use Optional<> instead and say something diagnostic whenever a request fails. API call methods are annotated with @RequiresRole(allOf / anyOf / any) to help a given requester figure out what they're allowed to download.

Remove TODO to use an enum (it's not appropriate) Because the judgement types are nominaly configurable (even though they don't appear to actually correspond to anything in judgement_types) there's no chance of defining a fixed set of outcomes in advance.

2017-12-30

Change category from string to uint64

Tool to serialise the entire api/v3 for a contest The saved format is an EntireContest proto which has very little structured information and is just bundling up all the responses from api/v3 endpoints. Makes replaying a contest offline later possible as long as there's something able to read the pb.txt out again and marshal it back into a contest --- which is the next step for this.

2017-12-03

Fix name of judging::submission, was submission_id

2017-07-21

Extend ScoreboardModel with listener events Plus a test to make sure they fire and update the model properly in the case of submissions, which is the only thing we'll be supporting properly in the near future.

2017-01-04

Add a ScoreboardModel, implement in javafx version Including this monolith of a comment which is A Good Idea but will have to wait until another night to resolve: /** * TODO: Move this into tests for the scoreboard lib. Possibly * expose in the scoreboard library too, with a syntax along * the lines of: * <code> * ScoreboardMocks.FakeModel.newBuilder() * .setProblems( "A", "B", "C", "D") * .addRow("Team 1", SOLVED, SOLVED, PENDING, FAILED) * .addRow("Team 2", SOLVED, PENDING, PENDING, FAILED) * .addRow("Team 3", FAILED, null, null, PENDING) * .build() * </code> */

More tidying up of BUILD files for various APIs

2017-01-01

Make annotations.proto a proto3-syntaxed proto Since it doesn't really make a difference and it's nice to not use the dodgy old syntax.

2016-12-31

Replace **Model classes with protobufs for now And load them in with a scoreboard.DomjudgeRest class that wraps up a gson reader in the appropriate annotation magic and uses it to translate fetched json into structured objects. This takes a fair bit of the cruft out of the Executive class (the commandline scoreboard viewer). Which is good because it's supposed to essentially be a commandline parser that prints out its results in a reasonably nice format.

2016-12-30

Initial commit Starting off with a program that just dumps out the results of a contest into stdout. Example invocation: bazel run :console -- --url https://{server}/domjudge/api None of this is particularly well-written or organised in its current state: - the first round of experimental code lives in Executive.java instead of separate controllers. - http requests are synchronous and not cached. - models are represented as raw Gson objects. The plan is to instead convert from JSON into a Java format exactly once and use strictly protobufs from then on. - the protobuf definition that does exist at the moment is just a useless stub with no relation to the project other than to confirm it actually builds something usable.