Vivint's Game of Codes 2017 (this site) consists of a series of problems which you need to write programs to solve. For each problem, you will need to check out a Git repo (listed at the bottom of each problem page), write your program, and then push the source code you've written to solve the problem. Your program will be run against test cases and its performance will be measured.
Part of succeeding in this contest involves being able to clone and push changes with the Git version control system. You may want to read documentation about Git if you aren't yet familiar.
To clone a project repo, you will need to have added an SSH key to your Github profile. Once you have done that, ensure that your SSH key is listed on your account page and is in your local SSH keychain. Github has additional help on their help site.
Once you are squared away with Github and your SSH key is on your account page, you'll just need to run the problem-specific Git command listed at the bottom of each problem page.
When you're ready to give a problem a shot, simply push your change to our
git push origin master (or to another branch, it
doesn't matter). We listen for incoming git refs, make tags, and run tests on
the git refs you push.
If you'd like to trigger a test rerun for the same code, you can amend your commit and force-push, you can push to a new remote branch, or you can push a new tag.
We've created a collection of "hello world" sample applications that work in our jail (but don't actually solve any problems). You can visit them here.
Each problem has a certain amount of test cases associated with it. When you submit a solution to a problem, the test cases are run against your solution and the time your solution takes to solve the problem is measured.
The solution that passes the most amount of test cases is chosen as your best solution to the problem. If multiple solutions pass the same amount of test cases, the one with the shortest runtime is chosen.
Your total score is dependent on the best submitted solution to each problem. You are ranked on the number of total test cases your best solutions have passed (highest to lowest), and then by the sum total execution time (lowest to highest).
The test environment is Debian in a restricted jail. The following toolchains have been used by us to solve the problems in this contest:
The following toolchains are also installed but not completely tested. They might work just fine, and if they don't we'll do our best to fix them, but we reserve the right to pull support for these languages if fixing them causes unfairness to competitors who solved problems with one of the already tested toolchains.
Your program is run through three separate phases,
each with a one minute time limit.
In the compilation phase, your working tree (
/tmp are mounted read/write, and if you have a
make is run inside your working
tree. The execution time of the compilation phase is limited, but does not
count against test time.
HOME are set for you (to
stderr are given
back to you during compilation.
In the example phase, 1 or more example tests are run, by invoking
./run inside your working tree (
./run could be a
script checked in by you or a binary built during the compilation step).
/tmp is unmounted and everything else is mounted read-only.
stdout is used for test purposes, but
stderr is given
back to you. Example tests do not count towards the leaderboard, and only serve
to help you develop with our restricted environment.
The test phase is identical to the example phase, except that
stderr is no longer sent back and no output from your program
is provided to you. Your program is graded for how many tests you pass and
how fast your program runs.