a template repo for an autograded assignment
- click the button to use this template
- give your repo a descriptive name for your assignment
- keep the repo private
- clone your repo into the same directory as your fork of autograder-core
- e.g.
user@machine:~/autograders/$ ls autograder-core hello-world-autograder
- e.g.
- go ahead and make
run_autograder
executable:chmod u+x run_autograder
There are two TODO(you)
s that you must do:
- make sure you have deploy keys.
- the instructions for doing that are in
setup.sh
and in thisREADME.md
under make a deploy key ⚠️ if your editor uses CRLF the deploy keys will not work. Ensure that your document is LF only.
- the instructions for doing that are in
- set your username and repository for the assignment-specific content
- change
your_username
to your GitHub username - change
repository_for_assignment
to the name of your repo - example: if my assignment repo is https://github.com/philipritchey/hello-world-autograder, then
username=philipritchey
repository=hello-world-autograder
- change
There is one TODO?(you)
that you may need to do:
- install dependencies
valgrind
is used for finding memory errors in c++ programsnum-utils
is used for summarizing coverage of java programspython3.8
or later is required byrun_tests.py
- you can/should add any other dependencies that your tests need
There are two TODO(you)
s that you must do:
- define the expected language
- currently, the following languages are supported:
c++
java
- currently, the following languages are supported:
- list the files that the student must submit
There is one TODO?(you)
that you may need to do:
- list the files that are provided by the instructor
- these are files which are needed for testing, but which the student is not responsible for submitting
- a subset of them may have been given to the students in starter code, but it is not necessary
- do not assume that files you include here are secret. it may be possible for a clever student to access them.
- you should not need to change anything, but you can if you need to (i.e. you know what you are doing)
- make sure you have created both
deploy_key
for your assignment-specific repoautograder_core_deploy_key
for your fork of the autograder-core repo
the <language>
must be either c++
or java
. i.e. tests/c++
or tests/java
.
- test specifications go in file(s) named
X.tests
, e.g.foo.tests
,bar.tests
, etc.- documentation for writing test specifications is at [/path/to/test_spec_documentation](Test Specification Documentation)
- the basic format of a test specification looks like this:
/* @name: add small numbers @points: 5 @type: unit @target: calculator.cpp */ <test> EXPECT_EQ(add(867, 5309), 6176); </test>
- all files containing test specifications (i.e.
X.tests
) must be in the top level of the directory- e.g. like this:
tests/c++/foo.tests
andtests/c++/bar.tests
.
- e.g. like this:
- i/o test resources go in
io_tests/
- each test should be in its own folder with a descriptive name, e.g.
io_tests/example/
- each test must have two plaintext files (names are arbitrary):
- a file that specifies the input to be provided to the program under test through standard input, e.g.
input.txt
- a file that specifies the expected output that the program under test should print to standard output, e.g.
output.txt
- a file that specifies the input to be provided to the program under test through standard input, e.g.
- the actual organization of this folder is abritrary since paths are provided in the test specification
- but, it is to your benefit to keep it well-organized
- each test should be in its own folder with a descriptive name, e.g.
- script (custom) test resources go in
script_tests/
- each test should have a descriptive name, e.g.
side_channel_attack.sh
- complex tests (e.g. those which are composed of several files) should be in their own descriptively-named folders
- the actual organization of this folder is abritrary since paths are provided in the test specification
- but, it is to your benefit to keep it well-organized
- each test should have a descriptive name, e.g.
⚠️ when running tests, the contents of thesubmission
/solution
,provided
, andtests
directories are copied into a directory namedtestbox
(along with all other required files, e.g. from the core)- only the required/expected files (as specified in
run_autograder
) fromprovided
andsubmission
/solution
are copied. - then, all the
X.tests
files are concatenated into one file that lives at the root oftestbox
, e.g.testbox/tests.cpp
- paths in your tests should be relative to the root of
testbox
- this might confuse your IDE, so don't panic if it says it can't find a reference. when in doubt, test.
- only the required/expected files (as specified in
- you can write your own code to test your tests.
- put your code in
solution/
- the
solution/
directory is ignored per.gitignore
.
- the
- when running tests locally, the autograder detects that it is not on gradescope and will pull the "submitted" code from
solution
.
ssh-keygen -t ed25519 -C "gradescope"
save it as ./deploy_key
with no passphrase
mv ./deploy_key ./secrets/deploy_key
to move the secret key to the secrets/
directory
on GitHub, add contents of ./deploy_key.pub
to your assignment-specific repo as a new deploy key
cp /path/to/autograder_core_deploy_key ./secrets/autograder_deploy_key
if you don't have one, get one!
make
creates the file autograder.zip
- create a programming assignment
- upload
autograder.zip
- base image os: Ubuntu
- base image version: 22.04
- base image variant: JDK 17
- update autograder
- test autograder
- check settings
- dates, times
- submission methods
- ignored files
- container specifications
- timeout