Drumor on adminboard
Improve queue page with an admi… (compare)
Drumor on make_multiple_tasks_inaccessible
simplifying UX (compare)
Drumor on reset_submission_state
deplacing button and page manag… (compare)
Drumor on save_local_storage
surround with try catch to avoi… (compare)
Drumor on save_local_storage
correcting implem of webstorage… (compare)
anthonygego on course_yaml_db_new
Dirty remove of course_factory Dirty remove of task_factory Update webdav for wsgidav >= 3.0 and 9 more (compare)
@jamesrobb PR #275 will probably be merged before the release. There are no other big change planned for this. Documentation update will then be necessary as well as an update script. Actually, you can use what is in the master branch, but you'll face the following difficulties : docs are not updated and migration from v0.4 may be tricky.
First of all, to solve the potentiel username clash of two authentication methods and better integrate other methods, every user now has an INGInious account in database for which he can choose his/her username, and link this account to its authentication method login. If you did not use the database authentication method, want to keep current data and be sure v0.5 usernames will still match the v0.4 ones, you will have to create the user accounts in database with the appropriate binding. I will see If I can rewrite and publish the script I wrote for UCLouvain in order to make this process automatic.
Secondly, LTI has been integrated into the webapp. The launch URL is now : http[s]://your_hostname/lti/courseid/taskid and you have to put the key and secrets into the course settings. Users using INGInious trough LTI will have to bind their webapp account the first time. This binding is definitive for the student and there is still no way to delete this binding from the webapp interface. This should not be a common issue.
Thirdly, in case you're using it, SAML authentication method ACS link has changed, so you'll need to update the metadata at the IdP side...
Fourthly, tasks subproblem types has been renamed from 'multiple-choice' to 'multiple_choice', 'code-single-line' to 'code_single_line' and 'code-file' to 'file'. This can be changed easily using
sed -i 's/old/new/g' **/**/task.yaml.
Eventually, submissions input are now stored in binary instead of base64, the update is currently made at the inginious-webapp startup, but can be stopped by some servers like uwsgi on heavy databases, which detect the update process as a non-responding script and do a timeout...
@jamesrobb Probably by the end of the month. The new link to the ACS is
/auth/callback/<auth_method_id>. Each auth plugin now require an
id field in the
configuration.yaml file. The base container files are available on Github in the
base-containers folder. You can build them by using
docker build -t ingi/inginious-c-base . in the
base folder and so one for other containers.
The new inginious.org site is still under work. I'm putting back some additional info as soon as I can.
@anthonygego cool, I might just wait to install (again) when you actually release. We had an iffy debut at my university with inginious when I tried to do postgres containers (so each student would have an isolated instance of postgres to code against). Not sure if it was my setup or what, but the file system on my VM would fill up entirely with the docker storage layer files until there was no space left, and often the inginious messaging system for running containers would stop working.
I'm optimistic with a fresh VM and a new version I can do some proper testing and hopefully figure out what went wrong. We really like the inginious and are eager to have our students using it.
/var/lib/docker/devicemapper/directory would continue to swell in size until all disk space was consumed. Not sure why, but it seems like the disk space that was occupied by a container while it was running wasn't freed up after it was shut down.
We are currently working on the deployment of a fork from INGInious at our University. At first we had the idea to use docker to deploy the webapp along with a bunch other microservices (a linter, and a visualizer for the code), however we have had a few issues in the process, namely how to put INGInious-webapp inside a container, has anyone tried something similar? Now we decided to have INGInious-webapp inside a lighttpd server, so we would like to know if you have some sort of a deployment script or some kind of automation in the process of deployment.