autolab/docker

Easy Docker Compose installation for Autolab

Autolab is a course management service, initially developed by a team of students at Carnegie Mellon University, that enables instructors to offer autograded programming assignments to their students over the Web. The two key ideas in Autolab are autograding, that is, programs evaluating other programs, and scoreboards.

Autolab also provides other services that instructors expect in a course management system, including gradebooks, rosters, handins/handouts, lab writeups, code annotation, manual grading, late penalties, grace days, cheat checking, meetings, partners, and bulk emails.

Since 2010, Autolab has had a transformative impact on education at CMU. Each semester, it is used by about 5,000 CMU students in courses in Pittsburgh, Silicon Valley, Qatar, and Rwanda. In Fall, 2014, we are releasing Autolab as an open-source system, where it will be available to schools all over the world, and hopefully have the same impact it's had at CMU.

Subscribe to our mailing list to receive announcements about major releases and updates to the Autolab Project.

Try It Out

We have a demo site running at https://nightly.autolabproject.com/. See the docs for more information on how to log in and suggestions on things to try.

Installation

We released new documentation! Check it out here.

Testing

Setting up Tests

1. Add a test database in database.yml

2. Create and migrate the database.

   RAILS_ENV=test bundle exec rails autolab:setup_test_env

   Do not forget to use RAILS_ENV=test bundle exec in front of every rake/rails command.

3. Create necessary directories.

   mkdir tmp/
   

Running Tests

After setting up the test environment, simply run spec by:

bundle exec rails spec

You may need to run RAILS_ENV=test bundle exec rails autolab:setup_test_env when re-running tests as some tests may create models in the database.

You can also run individual spec files by running:

rake spec SPEC=./spec/<path_to_spec>/<spec_file>.rb

Rails 5 Support

Autolab is now running on Rails 6. The Rails 5 branch can be found on master-rails-5. We will not be backporting any new features from master to master-rails-5, and we have discontinued Rails 5 support.

Updating Docs

To install mkdocs, run

pip install --user mkdocs

We rely on the mkdocs-material theme, which can be installed with

pip install --user mkdocs-material

To run and preview this locally, run:

mkdocs serve

Once your updated documentation is in master, Jenkins will automatically run a job to update the docs. You can trigger a manual update with

mkdocs gh-deploy

This will build the site using the branch you are currently in (hopefully master), place the built HTML files into the gh-pages branch, and push them to GitHub. GitHub will then automatically deploy the new content in gh-pages.

Contributing

We encourage you to contribute to Autolab! Please check out the Contributing to Autolab Guide for guidelines about how to proceed. You can reach out to us on Slack as well.

License

Autolab is released under the Apache License 2.0.

Using Autolab

Please feel free to use Autolab at your school/organization. If you run into any problems, you can reach the core developers at [email protected] and we would be happy to help. On a case-by-case basis, we also provide servers for free. (Especially if you are an NGO or small high-school classroom)

Changelog

v2.12.0 (2024/01/20) Attachment categories and visual cues

• Ruby upgraded to 3.2.2
• Rails upgraded to 6.1.7.6
• Instructors can now specify a category and "release at" date for attachments
• Assessment start / end dates are now shown on course homepages

v2.11.0 (2023/05/21) LTI Settings UI, extensions metrics, and simultaneous extension creation

• Introduced UI to manage LTI integration settings
• Added extension metrics for instructors to monitor students by number of extensions granted
• Instructors can now create extensions for multiple students at once

v2.10.0 (2023/01/13) LTI Integration, Generalized Feedback, and Streaming Output

• Autolab now supports roster syncing with courses on Canvas and other LTI (Learning Tools Interoperability) services. For full instructions on setup, see the documentation.
• Streaming partial output and new feedback interface
• Generalized annotations

For older releases, please check out the releases page.

docker's Issues

Failed due to Autolab dependencies

I am attempting to install the current docker version and run into this issue in the Autolab folder

---> Running in 142f1a15f1f8
Required ruby-2.6.6 is not installed.
To install do: 'rvm install "ruby-2.6.6"'
Warning: the running version of Bundler (1.17.2) is older than the version that created the lockfile (1.17.3). We suggest you upgrade to the latest version of Bundler by running gem install bundler.
Your Ruby version is 2.6.7, but your Gemfile specified 2.6.6
The command '/bin/sh -c bundle install' returned a non-zero code: 18
ERROR: Service 'autolab' failed to build : Build failed

Trying to bump this to 2.6.7 in the Gemfile causes even more depedency issues.

tangoJobManager looping after docker-compose up

Hi,

I am installing this for the first time, and when I take step 6 Run the containers: docker-compose up, everything seems to be working, except the tangoJobManager, which seems to be looping.

The message that I get is as follows:

tango      | 2020-10-22 17:27:54,917 INFO success: tangoJobManager entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
tango      | 2020-10-22 17:27:54,919 INFO spawned: 'tango' with pid 126
tango      | 2020-10-22 17:27:55,920 INFO success: tango entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
tango      | 2020-10-22 17:27:59,065 INFO exited: tangoJobManager (exit status 1; not expected)

This sequence of messages keeps appearing. It seems to be encountering some problem during initialization.

Can you help me with this?

Resolve DOCKER_VOLUME_PATH ambiguity

DOCKER_VOLUME_PATH is used both as an environment variable in docker-compose.yml as well as a variable in Tango's config.py, which may be confusing for new users setting up as the environment variable is meant to be modified but not the one in Tango's config.py

Allow updating to a specific Autolab version

Currently, make update pulls the latest Autolab (and Tango) versions. Also, it doesn't pull the latest changes from the docker repo.

However, this might be undesirable as the master branches could be unstable.

Possible approach

• Create autolab/docker releases in tandem with autolab/Autolab releases
• make update to support optional specification of autolab/docker release tag. If specified, it should checkout the docker repo at that tag and pull the corresponding submodules (git submodule update)

Mossnet script needs to be added after every deployment/down/up

The mossnet script should be added inside a vendor directory that is not persisted, which means it needs to be copied after every deployment or compose down/up. I do not think it is a good idea to persist the vendor directory, and I am unable to persist the script alone because when the Autolab instance is first setup the mossnet script does not exist and docker will instead create a directory called ./vendor/mossnet.

Possible solutions:

• Add vendor to autolab's volumes in docker-compose.yml.
• Move mossnet to some other directory, add the script and directory to the autolab repository, and persist it in autolab's volumes in docker-compose.yml.

Permission problems with volumes mounted in docker-compose file

Hi,

I am currently using the docker-compose file provided in this repository, and I could see that when I run docker-compose up and try to access the service in the browser, I get an error message like the figure below:

When I investigate further, I can see that the output of the autolab container is as follows:

autolab    | App 124 output: Using /usr/local/rvm/gems/ruby-2.6.6
autolab    | App 124 output: Error: The application encountered the following error: cannot load such file -- /home/app/webapp/config/environments/production.rb (LoadError)
autolab    | App 124 output:     /usr/local/rvm/gems/ruby-2.6.6/gems/activesupport-5.2.0/lib/active_support/dependencies.rb:283:in `require'
autolab    | App 124 output:     /usr/local/rvm/gems/ruby-2.6.6/gems/activesupport-5.2.0/lib/active_support/dependencies.rb:283:in `block in require'
autolab    | App 124 output:     /usr/local/rvm/gems/ruby-2.6.6/gems/activesupport-5.2.0/lib/active_support/dependencies.rb:249:in `load_dependency'
autolab    | App 124 output:     /usr/local/rvm/gems/ruby-2.6.6/gems/activesupport-5.2.0/lib/active_support/dependencies.rb:283:in `require'

I checked and the file config/environments/production.rb is in the correct folder. So, I looked at the permissions in the /home/app/webapp, and they are as follows:

root@37329f872158:/home/app/webapp# ls -la
total 200
drwxr-xr-x 1 app  app   4096 Oct 23 02:37 .
drwxr-xr-x 1 app  app   4096 Oct 22 12:30 ..
drwx------ 1 app  app   4096 Oct 22 12:08 app
drwx------ 1 app  app   4096 Oct 22 12:08 bin
drwx------ 1 app  app   4096 Oct 22 12:09 config
-rwx------ 1 app  app    158 Oct 22 12:08 config.ru
-rw------- 1 app  app  32198 Oct 22 12:08 config.zip
-rw------- 1 app  app   6449 Oct 22 12:08 CONTRIBUTING.md
drwxr-xr-x 2 root root  4096 Oct 22 12:34 courses          <-- volume
drwx------ 3 1001 1001  4096 Oct 23 02:32 db          <-- volume
drwx------ 1 app  app   4096 Oct 22 12:09 docker
-rw------- 1 app  app   1418 Oct 22 12:09 Dockerfile
-rw------- 1 app  app      6 Oct 22 12:08 .dockerignore
drwx------ 1 app  app   4096 Oct 22 12:09 docs
drwx------ 1 app  app   4096 Oct 22 12:08 examples
-rw------- 1 app  app   3415 Oct 22 12:08 Gemfile
-rw------- 1 app  app   9482 Oct 22 12:09 Gemfile.lock
drwx------ 1 app  app   4096 Oct 22 12:08 .github
-rw------- 1 app  app    734 Oct 22 12:09 .gitignore
drwx------ 1 app  app   4096 Oct 22 12:08 lib
-rw------- 1 app  app  11324 Oct 22 12:08 LICENSE
drwxr-xr-x 1 app  app   4096 Oct 23 02:37 log
-rw------- 1 app  app   1227 Oct 22 12:09 mkdocs.yml
drwx------ 1 app  app   4096 Oct 23 02:37 public
-rwx------ 1 app  app    273 Oct 22 12:08 Rakefile
-rw------- 1 app  app    604 Oct 22 12:08 .rake_tasks~
-rw------- 1 app  app   5585 Oct 22 12:09 README.md
-rw------- 1 app  app     81 Oct 22 12:08 .rspec
-rw------- 1 app  app   4592 Oct 22 12:08 .rubocop_todo.yml
-rw------- 1 app  app    873 Oct 22 12:08 .rubocop.yml
-rw------- 1 app  app      6 Oct 22 12:08 .ruby-version
drwx------ 1 app  app   4096 Oct 22 12:08 script
drwx------ 1 app  app   4096 Oct 22 12:08 spec
drwx------ 1 app  app   4096 Oct 22 12:08 templates
drwxrwxr-x 3 app  app   4096 Oct 23 02:37 tmp
-rw------- 1 app  app   1658 Oct 22 12:08 .travis.yml

The files within config are:

root@37329f872158:/home/app/webapp# ls -la config
total 108
drwx------ 1 app  app  4096 Oct 22 12:09 .
drwxr-xr-x 1 app  app  4096 Oct 23 02:37 ..
-rwx------ 1 app  app  5414 Oct 22 12:08 application.rb
-rwx------ 1 1001 1001  699 Oct 22 12:09 autogradeConfig.rb          <-- volume
-rwx------ 1 app  app   699 Oct 22 12:08 autogradeConfig.rb.template
-rwx------ 1 app  app   128 Oct 22 12:08 boot.rb
-rw------- 1 app  app   116 Oct 22 12:08 cable.yml
-rw------- 1 app  app   201 Oct 22 12:09 database.docker.yml
-rwx------ 1 app  app   667 Oct 22 12:08 database.travis.yml
-rw------- 1 1001 1001  201 Oct 22 12:09 database.yml          <-- volume
-rwx------ 1 app  app   488 Oct 22 12:08 database.yml.template
-rwx------ 1 app  app   128 Oct 22 12:08 environment.rb
drwx------ 1 app  app  4096 Oct 22 12:09 environments
drwx------ 1 app  app  4096 Oct 22 12:36 initializers
drwx------ 1 app  app  4096 Oct 22 12:08 locales
-rw------- 1 app  app  9693 Oct 22 12:08 newrelic.yml
-rwx------ 1 app  app    46 Oct 22 12:08 preinitializer.rb
-rw------- 1 app  app  2005 Oct 22 12:08 puma.rb
-rwx------ 1 app  app  5096 Oct 22 12:08 routes.rb
-rw------- 1 app  app   473 Oct 22 12:09 school.yml
-rw------- 1 app  app   473 Oct 22 12:08 school.yml.template
-rw------- 1 app  app   965 Oct 22 12:08 secrets.yml
-rw------- 1 app  app   111 Oct 22 12:08 spring.rb

What we observe is that all the files mounted as volumes by the docker-compose.yml file have different permissions, which make them inaccessible by the application.

I noticed that all these files are copied to the container in the ./Autolab/Dockerfile, but they are again mounted by the docker-compose.yml.

I could solve the issue by removing lines 31-36 of the docker-compose.yml file and running docker-compose build again. Then, autolab runs correctly after docker-compose up.

Since there is a comment stating that these volumes should be explicit, I didn't submit a PR, but I'd like to make you aware of this.

Missing 404 image

Missing images/donkey_kong_lost.jpg in docker repo

Usage: Autolab/public/404.html: ""

State minimum docker-compose version necessary

I have found out that the docker-compose file version 3.8, which is used here, is only available from version 1.25.5. My Ubuntu apt installed version 1.17.1, and wasn't working with the docker-compose file.

The announcement of the file version 3.8 can be seen here: https://github.com/docker/compose/releases/tag/1.25.5

I suggest stating the minimum version to avoid confusion.

Tango autograding issues

Seems like the feedback file ('/opt/TangoService/Tango/volumes/prod-1000-autograding_image/feedback') was not found

DEBUG|2020-12-03 21:36:21,883|JobQueue|assignJob| Acquired lock to job queue.
DEBUG|2020-12-03 21:36:21,883|JobQueue|assignJob| Retrieved job.
INFO|2020-12-03 21:36:21,883|JobQueue|assignJob|Assigning job ID: 2
DEBUG|2020-12-03 21:36:21,884|JobQueue|assignJob| Releasing lock to job queue.
DEBUG|2020-12-03 21:36:21,884|JobQueue|assignJob| Released lock to job queue.
INFO|2020-12-03 21:36:21,884|JobManager|Dispatched job [email protected]:2 to autograding_image [try 0]
DEBUG|2020-12-03 21:36:21,921|Worker|Run worker
DEBUG|2020-12-03 21:36:21,923|Worker|Assigning job to preallocated VM
INFO|2020-12-03 21:36:21,923|Worker|Assigned job [email protected]:2 existing VM prod-1000-autograding_image
DEBUG|2020-12-03 21:36:21,924|Worker|Assigned job to preallocated VM
DEBUG|2020-12-03 21:36:21,924|Worker|Job [email protected]:2 waiting for VM prod-1000-autograding_image
DEBUG|2020-12-03 21:36:21,924|Worker|Waiting for VM
DEBUG|2020-12-03 21:36:21,924|Worker|Waited for VM
INFO|2020-12-03 21:36:21,924|Worker|VM prod-1000-autograding_image ready for job [email protected]:2
DEBUG|2020-12-03 21:36:21,962|LocalDocker|Copied in file courselabs/REPLACE_ME_SECRET_TANGO_KEY-15-213-hello/[email protected]_2_hello.c to /opt/TangoService/Tango/volumes/prod-1000-autograding_image/hello.c
DEBUG|2020-12-03 21:36:21,963|LocalDocker|Copied in file courselabs/REPLACE_ME_SECRET_TANGO_KEY-15-213-hello/autograde-Makefile to /opt/TangoService/Tango/volumes/prod-1000-autograding_image/Makefile
DEBUG|2020-12-03 21:36:21,963|LocalDocker|Copied in file courselabs/REPLACE_ME_SECRET_TANGO_KEY-15-213-hello/autograde.tar to /opt/TangoService/Tango/volumes/prod-1000-autograding_image/autograde.tar
INFO|2020-12-03 21:36:21,963|Worker|Input copied for job [email protected]:2 [status=0]
DEBUG|2020-12-03 21:36:21,964|LocalDocker|Running job: ['docker', 'run', '--name', 'prod-1000-autograding_image', '-v', '/opt/TangoService/Tango/volumes/prod-1000-autograding_image/:/home/mount', 'autograding_image', 'sh', '-c', 'cp -r mount/* autolab/; su autolab -c "autodriver -u 100 -f 104857600 -t 180 -o 1024000 autolab > output/feedback 2>&1";                         cp output/feedback mount/feedback']
DEBUG|2020-12-03 21:36:31,114|LocalDocker|runJob returning 0
INFO|2020-12-03 21:36:31,114|Worker|Job [email protected]:2 executed [status=0]
ERROR|2020-12-03 21:36:31,382|Worker|Internal Error
Traceback (most recent call last):
  File "/usr/lib/python3.6/shutil.py", line 550, in move
    os.rename(src, real_dst)
FileNotFoundError: [Errno 2] No such file or directory: '/opt/TangoService/Tango/volumes/prod-1000-autograding_image/feedback' -> 'courselabs/REPLACE_ME_SECRET_TANGO_KEY-15-213-hello/output/[email protected]_2_hello_autograde.txt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/TangoService/Tango/worker.py", line 277, in run
    ret["copyout"] = self.vmms.copyOut(vm, self.job.outputFile)
  File "/opt/TangoService/Tango/vmms/localDocker.py", line 165, in copyOut
    shutil.move(volumePath + 'feedback', destFile)
  File "/usr/lib/python3.6/shutil.py", line 564, in move
    copy_function(src, real_dst)
  File "/usr/lib/python3.6/shutil.py", line 263, in copy2
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.6/shutil.py", line 120, in copyfile
    with open(src, 'rb') as fsrc:
FileNotFoundError: [Errno 2] No such file or directory: '/opt/TangoService/Tango/volumes/prod-1000-autograding_image/feedback'
INFO|2020-12-03 21:36:32,616|Preallocator|createVM|calling initializeVM
INFO|2020-12-03 21:36:32,616|Preallocator|createVM|done with initializeVM
DEBUG|2020-12-03 21:36:32,618|Preallocator|createVM: Added vm 1002 to pool autograding_image

Better way of dealing with schema.rb conflicts

When running make update, there will be conflicts with schema.rb whenever we add new migrations to Autolab as the user will also have run the migrations previously. There should be a more transparent way of dealing with this.