UBC-DSCI / rudaux

LMS + External Tool Workflow Orchestration
https://ubc-dsci.github.io/rudaux
MIT License
7 stars 5 forks source link

Two courses one rudaux - student side snapshots #96

Closed ttimbers closed 3 years ago

ttimbers commented 3 years ago

@trevorcampbell - I am taking baby steps to be able to do two courses one rudaux - student side snapshots. This PR is not yet meant to be accepted, but showing you what I am attempting to add a course slug (e.g., "prog" for Programming for Data Science" to the snapshot name so that chaos doesn't ensue at snapshot time when two courses try to name the snapshots assignment1...

Am I on the right track?

Also, I found it a bit hard to test ahead of the due date as when I run sudo rudaux snapshot --dry-run before the due date there is nothing really returned (I guess because no snapshot is needed). Is there a command line tool to ask what a snapshot name should be for assignments where the due date has not passed?

trevorcampbell commented 3 years ago

re: testing -- there isn't a great way to do it. We really need to fill out that dsci100 development canvas shell with a few fake assignments/submissions etc for unit testing.

Also can we get rid of the netlify app? It always flags totally fine PRs as failing a bunch of checks

ttimbers commented 3 years ago

don't add a slug; the right solution is to use the course.name variable. otherwise we have two config variables that essentially serve the same purpose, which is confusing

While I agree it is the right move, I am going to proceed with this for the first time around, as there are a lot of infrastructure changes that will need to also happen for me to use course_name correctly...

Also can we get rid of the netlify app? It always flags totally fine PRs as failing a bunch of checks

Yep, will do.

ttimbers commented 3 years ago

What I have left to change:

grader_basename

have Assignment class constructor read in config:

So change to:

class Assignment(object):
    def __init__(self, canvas_dict, config):
        self.__dict__.update(canvas_dict)
        self.snapshot_taken = False
        self.override_snapshots_taken = []
        self.grader_workloads = {}
        self.course_slug = config.course_slug

so it can read in the course slug

rudaux configs on student machine

change where to copy snapshots from and to in submission.py

So I think if I change those two things, I should be in business :grimacing:

ttimbers commented 3 years ago

Two courses also needs two deploy keys - here's a gist on how to do this: https://gist.github.com/FlorianBouron/208c77aff253fc178a4a0ad6639f1412

ttimbers commented 3 years ago

To do that you need a config file in /root/.ssh like this:

Host repo1
  HostName github.ubc.ca
  User git
  IdentityFile ~/.ssh/repo1
  IdentitiesOnly yes

Host repo2
  HostName github.ubc.ca
  User git
  IdentityFile ~/.ssh/repo2
  IdentitiesOnly yes

And then the git clone for repo1 is: git clone repo1:org/repo1

ttimbers commented 3 years ago

So to make this work with rudaux use repo1:org/repo1 as the format for c.instructor_repo_url in rudaux_config.py instead of a standard git clone url that looks for ~/.ssh/id_rsa.

ttimbers commented 3 years ago

For solutions and feedback for the multiple course situation, it would be nice to put these in a directory for each course...

trevorcampbell commented 3 years ago

@ttimbers I'll make sure these things are handled as part of the big change in #95

But

For solutions and feedback for the multiple course situation, it would be nice to put these in a directory for each course...

The solutions and feedback are stored in each grader folder currently -- is there a reason that isn't a good place?

trevorcampbell commented 3 years ago

Just posting here since it's related -- we also need to make sure that when one course finishes and a new one starts that uses the same server, that we protect against issues related to that (same course name, for example, or even with different course names)

currently we include course group name in grader account names. This should be fine, assuming the server is cleaned up between semesters.

trevorcampbell commented 3 years ago

I'm closing this PR as it's really out of date now. But I'm going to open a new issue regarding multiple deploy keys and add it to the Version 1.0 project.