Currently, when a submission is made through the web GUI, it is pushed into a priority queue which dispatches jobs to available Agents, according to the job and Agent types. That means that current Agents are only pull-based, they lazily receive jobs when they are available to process them.
Such Agents are daemon processes that sleep most of the time, until they receive a new job to process. Also, the backend has to ensure that Agents are still alive before trying to send them new jobs.
As INGInious is primarily targeted for computer science courses, we have more and more requests for a VCS-based job submission system. For example, students are taught how to write automated tests and how to deploy CIs to run them, and how to use a VCS to handle versioning of their work. Hence, teachers want to trigger INGInious job submission when students push code to a hosted repository.
This would require a new kind of lightweight push-based Agents running as CI jobs within hosted repositories. Upon push on the repository, they fetch the related course task, evaluate the repository content and create a submission such as classical pull-based Agents. This submission must then be pushed to the INGInious backend to store it in the database and make it reachable through the web GUI such as any other submission.
Besides the more flexible way to handle jobs, this also lower the maintenance requirements for administrators. Such Agents are not running 24/7 and access must not be maintained on the backend side.
Fine-grained access to courses and tasks is enabled by #1061 and authorization of push-based Agents may be enabled by mTLS upon REST API push of a submission.
The security model is pretty much the same as Gitlab or GitHub self-hosted runners.
Currently, when a submission is made through the web GUI, it is pushed into a priority queue which dispatches jobs to available Agents, according to the job and Agent types. That means that current Agents are only pull-based, they lazily receive jobs when they are available to process them.
Such Agents are daemon processes that sleep most of the time, until they receive a new job to process. Also, the backend has to ensure that Agents are still alive before trying to send them new jobs.
As INGInious is primarily targeted for computer science courses, we have more and more requests for a VCS-based job submission system. For example, students are taught how to write automated tests and how to deploy CIs to run them, and how to use a VCS to handle versioning of their work. Hence, teachers want to trigger INGInious job submission when students push code to a hosted repository.
This would require a new kind of lightweight push-based Agents running as CI jobs within hosted repositories. Upon push on the repository, they fetch the related course task, evaluate the repository content and create a submission such as classical pull-based Agents. This submission must then be pushed to the INGInious backend to store it in the database and make it reachable through the web GUI such as any other submission.
Besides the more flexible way to handle jobs, this also lower the maintenance requirements for administrators. Such Agents are not running 24/7 and access must not be maintained on the backend side.
Fine-grained access to courses and tasks is enabled by #1061 and authorization of push-based Agents may be enabled by mTLS upon REST API push of a submission.
The security model is pretty much the same as Gitlab or GitHub self-hosted runners.