Skip to content

Conversation

@nrybowski
Copy link
Member

@nrybowski nrybowski commented Jul 18, 2025

This PR lays down the basics for #1059 and related features. For more details, see #1059.

TODO list

Git-based courses and tasks

  • Implement the FileSystemProvider interface for the Git-based FS. > Added with f5bf65c.
  • Git FSP-based courses. > Added with 93d996b.
  • Git FSP-based tasks.
  • Initialize sub-module upon task creation.
  • Abstract Gitolite interaction for course or task creation on remote.
  • Remote configuration through INGInious config file.
  • Handling $common directory.
    • Upon $common directory creation
      • Create course-scoped sub-module.
        - [ ] For each task, create a task-scoped sub-module.
    • Upon $common directory update:
      • Commit changes in the $common directory.
      • For each task, bump $common sub-module version.
      • Bump the course-scoped $common sub-module version.
    • Upon task addition, add the $common sub-module.
  • Version task edition and update course submodule reference.
    • Creation
    • Edition
    • Deletion
    • Upload
    • Rename
      - [ ] Handling $i18n directory?
      - [ ] Automated signed commit upon task / course modification at the web GUI.

@nrybowski nrybowski force-pushed the git-fs branch 2 times, most recently from 93d996b to 2872d0e Compare July 21, 2025 19:16
@nrybowski
Copy link
Member Author

Open question: How do we handle task migration with common directories?

Suppose we have courseA/task0 and courseB. The first course contains a $common directory: courseA/$common and courseA/task0/$common whose remote origin points towards remote:courseA/$common. courseB does not contain a $common directory.

We migrate courseA/task0 to courseB by adding a courseB/task0 sub-module whose remote still points to remote:courseA/$common. As courseB does not contain a $common directory, we can add courseA/$common submodule to courseB and update remotes from courseB/$common and courseB/task0/$common to remote:courseB/$common.

Now suppose that courseB already contains an unrelated $common sub-module.
How do we merge courseA/$common with courseB/$common?

With the addition of the GitFSProvider, many Git-related helpers will be added.
In order to keep the tests clearly organized, filesystem-related tests are
move in a dedicated python submodule.
@nrybowski
Copy link
Member Author

With this push, we moved away from GitPython to leverage pygit2 instead. See #1058 (comment).

@nrybowski nrybowski force-pushed the git-fs branch 8 times, most recently from 2b32697 to 37b97a4 Compare August 1, 2025 14:17
The GitFSProvider relies on Gitolite as the main authorization
layer for the project. This interface abstracts some gitolite
configuration manipulations such as adding a new course or a
new task to a given course.
Python3.10 will be EOL by the end of 2026.
We now use string formatting feature added with 3.12, hence
we deprecate older versions for INGInious v0.10.0
Upon course creation, we ensure that the course and its $common submodule
are initialized on the remote through gitolite configuration update. We
then locally create the course and the $common submodule repositories.
They contains the descriptors defined through the web interface. The
course and its $common submodule are then pushed on the remote.

This requires storing a private SSH key for users and propagating credential
information within the Git FSP to ensure commits authorship and remote
authentication.

This commit also improves the gitolite interface tests and adds specific
tests for the Git FSP.
This commit contains multiple changes.

First, the core containers have been bumped to RockyLinux 10 to access
the packaged version of python3.12.

Second, the initial DB setup script has been updated to load an initial
SSH private key for the superadmin. This key is used to authenticate on
the gitolite instance.
The frontend service image has been updated to leverage this extension
of the DB setup script on service startup.

Third, previous commits leverage a patched version of pygit2. While the
patch libgit2/pygit2#1395 is not available
through PyPi, we have to leverage a custom build of pygit2. However, the
packaged libgit2 version on RL10 is too old for current versions of
pygit2, hence we also have to custom build libgit2 and libssh2.
Upon task content edition, the modifications are versioned, and the
task submodule at the course level is updated.
@nrybowski
Copy link
Member Author

nrybowski commented Sep 12, 2025

After discussing with @anthonygego and @AlexandreDoneux, this PR will remain on hold until the course and task factories are correctly refactored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant