Teachers using private repo belonging to their user account

[EricPickup]

A lot of teachers have been using private repos created on their user account (rather than on the org) as their starter code repo.

This isn't an issue when they create the assignment because we're querying that repo on their behalf. The repo is accessible.

However, when a student accepts that assignment, we pick a random org owner's token to create a repo on the classroom org. If that random token is not the teacher who owns the starter repo, the repo is inaccessible.

I'm guessing we never noticed this because most orgs/classrooms will only have one owner (aka the teacher that owns the private repo). In reality, many classrooms contain multiple owners (TA's for example).

This is the actual reason templates were failing for the past few weeks and most likely has been the biggest cause of failure using porter as well.

[d12]

100/100 investigative work, nice work 😄

@EricPickup @shaunakpp I'd love for you to try to solve this in your last week - if possible. If you don't have time to implement anything, outlining a proposed fix for handoff to @education/classroom-reviewers to work on would be 💯

[EricPickup]

@shaunakpp let's set up some time today to work on this!

A couple solutions I've thought about..

1. When a new assignment is created or a new teacher/TA is added as a classroom owner, add them as collaborators to any starter code repositories. We'd definitely add some message to indicate this. We could check who created each assignment, grab their token and add all other classroom owners. This would help prevent reaching rate limits in our largest classrooms.

2. When creating a repo for the student, iterate through (or choose at random) the list of classroom owners and send a GET for the starter code repo on their behalf. If we get a 404, skip to the next owner. Once we get a successful response use their token. This is the safest way to do it and requires no unexpected changes to the teacher's repo. However, this does leave a higher chance of hitting the rate limits on large classrooms.

@d12 @shaunakpp let me know what you guys think.

[shaunakpp]

When a new assignment is created or a new teacher/TA is added as a classroom owner, add them as collaborators to any starter code repositories.

This may not work if the starter code repository is a public repository not belonging to the teacher or the organization.

When creating a repo for the student, iterate through (or choose at random) the list of classroom owners and send a GET for the starter code repo on their behalf. If we get a 404, skip to the next owner. Once we get a successful response use their token.

This makes an already long-running job longer, is it possible to short-circuit this step while assignment creation? Like, keep a list of user_ids that are valid owners/collaborators for the starter code repository and use one of them while creating the assignment repo for a student?

I'm also in favor of the second solution as it is not mutating anything on dotcom.

[EricPickup]

This may not work if the starter code repository is a public repository not belonging to the teacher or the organization.

This step wouldn't be necessary if it's a public repo!

keep a list of user_ids that are valid owners/collaborators for the starter code repository and use one of them while creating the assignment repo for a student?

The only issue I see with this is that even though it's unlikely collaborators for the repo can change at any time. It also still leaves the rate limit issue. 😬

I think we should wait to see what @d12 thinks before we get started since both methods have their ups/downs.

[BenEmdon]

Awesome job investigating this 👌 This was totally an oversight!

Issue with Proposed Solutions

Both suggested solutions 1. and 2. in #2222 (comment) rely on users maintaining access to their classroom organization. This would prevent classroom organizations form using GitHub organization access as they might normally.

If a ta/teacher is removed from their classroom organization, classroom would loose access to their privately owned starter code repos.

Users of classroom would be inconvenienced by this constraint (which could be perceived as unintuitive). Organization access should be able to be revoked for teachers/ta without causing disruption to classroom.

Potential Solution

A more stable solution would to copy the assignment creator's privately owned starter code repo to the classroom organization. This copy would serve as a base repo for the assignment and classroom would always maintain access to it (given that the classroom admins have the appropriate levels of access).

This approach has some bonus benefits:

• Assignment repos could always be template repos
• Assignment repos would not disappear if the source repo went from public to private
• Paid organizations wouldn't have to keep certain users in their organization for the purpose of maintaining access, which would cost them seat(s)

[shaunakpp]

This step wouldn't be necessary if it's a public repo!

Yes, but we currently store just the starter_code_repo_id so we wouldn't know whether the repo is public or not until we start the assignment creation process for a student. So, probably we'll need to add a flag like starter_code_repo_private to circumvent this added check if the repo is public.

The only issue I see with this is that even though it's unlikely collaborators for the repo can change at any time. It also still leaves the rate limit issue. 😬

We can keep user_ids as cache, and bust the cache if we get a 404, and retry the process. (This is a rare scenario, but worth handling).

[EricPickup]

@BenEmdon I really like this solution and think it's the most stable.

We could fork the repo over to the organization instead of copying using templates. That removes the extra step of making that repo into a template and also cover the plan that @d12 proposed related to this: #2032 where if the user doesn't have permission to make a repo into a template, we fork it and make the fork a template.

[shaunakpp]

@BenEmdon creating a fork looks like a good solution 👍.

We'll need to add clear messages that we are creating a fork in the organization, as currently picking a starter code repository creates no perceived side effects to the organization. But, with this implementation, we'll be adding a new repository to the org and at the same time make it a template.

[d12]

This makes sense to me 👍

As far as copying goes, we should be forking, not importing or template copying. The repo may not necessarily be a template repo, and we don't want to add further dependencies on the importer.

Keep in mind that GitHub forks are absurdly complex, there's a LOT of edge cases to worry about.
@BenEmdon 's point about not having to keep a seat in a paid org is depending on a bug that we've been trying to fix for 3 years now: https://github.com/github/github/issues/62000, so lets not depend on that always being the case.

That being said, make sure to test any assumed fork functionality before starting work, forks sometimes don't behave how you'd expect them to behave.

Let's also make sure we're looping in design here so that this is communicated properly to the end user, Teachers should understand why this repo is being copied into their org.