Freecodecamp: Low-friction way for campers to be able to commit their solutions to a GitHub repo

[QuincyLarson]

We are looking for a low-friction way for campers to be able to push their Free Code Camp challenge solutions to a GitHub repository.

We need to establish:

• is it possible to create, then write to, a camper's open source repository? (https://developer.github.com/v3/repos/#create)
• could we push a .md file with their solution to the repository?
• Is there an alternate way where the camper could download the solution .md file to a specific repository, then manually push it up to GitHub?

[raisedadead]

Hi @QuincyLarson ,

Possible Solution

I was looking into the Github API and this is some demo code that I tested:
https://gist.github.com/raisedadead/01ec9438e0db05ff54e6

I used one of the JavaScript Wrappers, for doing this from client side. Its mentioned in the API Docs here
Github.js by Michael Aufreiter.
I have seen it used in one of the other projects that I work with.

Which gives us answer to your queries:

Is it possible to create, then write to, a camper's open source repository? `

Yes, it is very much possible

Could we push a .md file with their solution to the repository?

Yes, of course.

Is there an alternate way where the camper could download the solution .md file to a specific repository, then manually push it up to GitHub?

I don't this would be required if we do the above.

Caveats?

• I used the Personal access token, this has to be replaced with the token that we already have for FCC. It would still work.
• Need to plan out cases like what if the user, modifies it outside the FCC editor environment.
• Things that will come along.

[SaintPeter]

@raisedadead Does this solution require a privilege escalation? IE: Will the FCC site have to explicitly request access to post the file? There is typically a callback and key exchange to make this work. Would it be possible for you to make a "test account" that you set up the GitHub "application" on, then try to get it to share your main account's code?

[raisedadead]

@SaintPeter Yes, that is correct, it would require, write privileges to user's repo. I did use a personal access token with requisite scopes to create repo, write etc. as per the scenario. I'll setup a test account and the demo app, and will share the details shortly.

[adamisntdead]

Following Up On This, Should I try continuing on this feature? I know there is an existing NPM module (node-github) that supports it, so it could be implemented fairly easily that way? maybe a button on the profile page of the user, next to each solution?

[raisedadead]

@adamisntdead sure thing, but you would have to find a way to do it client side.
This requires, escalation of privileges on the user's permission.

Currently when someone links their GitHub account we seek the basic profile level permission (scope:email), this has to be graceful enough to allow for repos (scope:public_repo)

Secondly this has to be client side, meaning we have to implement the GitHub Web Workflow.

My gist in the comments above may help you. Good luck. and thanks for looking into this.

[adamisntdead]

Shoud I try and write new client side code, or should I use something liek require.js or browserify to use an existing wrapper? thanks, adam

[raisedadead]

We are almost always a bit skeptical in using more libraries than it is necessary, mostly because it adds to the maintenance cost. So as long as possible, we should stick to native code and minimal libraries.

Well I certainly think its possible without any of the weight of require.js (its terrific yet heavy) and same is for browserify, but I'll let you make a call on that.

We are using react for our editor and it would be soon integrated to the main website. IMHO you should check how this can be played together.

Thanks.

[adamisntdead]

I have spent some time looking at it, and I noticed that this was implemented before, but anonymously, which defeats the purpose (it was also removed....)

I will be able to do it just fine without external modules, but the privileges needed from github would need to be escalated from 'email' to that and 'gist'. Is that ok?

[raisedadead]

Well, gist is not a great way to have store the solutions, because they can't be organised very cleanly, rather having a repo, and storing versioned solution files (markdown) would make more sense.

Also note that we would not be asking every camper for the escalated permission, but rather the first time they choose to store the solutions.

As long as we implement such a flow we should be good.

[adamisntdead]

Okay, well the sort of idea I had for how to make it work would be

1. User clicks 'Save Solutions to Github'
2. A repo named something like 'FreeCodeCamp-Solutions' is created
3. A New File For Each Challenge/Algorithm is Made called 'Solution.md' with info on the challenge, and the solution
4. Added To A Folder and Added To The Repo
5. When a change is made, the user can update the solution in the repo (Will be implemented at a later stage).

looking at the code for this, I know that you want to keep dependencies down, but it might mean a lot less code for this is we use a wrapper (such as github-api or octonode), but I could write it using the (already a dependency) request module, which is what I wrote the gist version in...
Any feedback on this would be appreciated @raisedadead, Thanks

[raisedadead]

The flow looks sweet to me. Again, we are totally cool to add a new dependency and concentrate on the logic that would be needed to save the solutions.

Just adding my opinions to the flow:

1. User "Clicks Save Solution to GitHub" button (available only when logged in*)
2. If Save button is clicked for first time (Setup the GitHub)
   
   
   
   1. Go through the steps of requesting additional permissions (write access to repo).
   
   
   2. Create a repo "Free-Code-Camp-Solutions" (ask user for a name, store it in user object*)
   
   
   3. Create a new file for each challenge "Challenge-Name-Solution-Submission-Date-Time.md" (let's keep it markdown)
   
   
3. If Setup the GitHub is done,
   
   
   
   1. Add a new file as shown above.
   
   
   2. If submitting a second time, that date/time stamped file will automatically handle such scenarios for us.
   
   

Note whatever I have marked as a * in the parentheses can be taken in a later stage.

Let's keep this flow as simple as we can, note I did not mention separate challenge category folders to avoid handling renaming them each time our curriculum changes, also we would want campers to be able to save multiple edition of their solutions (time stamped versioned files), so that the on us is on them to delete/keep them later in their repo.

I am super excited to see what you will come up with. Thanks a lot.
If you need any assistance you can ping me on Gitter to have a chat as well https://gitter.im/raisedadead

[raisedadead]

Sorry I forgot to mention that we can have a separate application registered that will request the write access, and separate the flow from the login access, that is the only way to define the different access scopes for different users (ones who wish to store vs ones who do not).

[adamisntdead]

Yes! thats great, I am really looking forward to working on this!

[QuincyLarson]

We may work on this in the future. Right now we have bigger priorities.

[ooade]

I suggest we make use of github gist later on. That would seem easier to integrate as well.

[QuincyLarson]

@marhyorh this is easier to integrate, but it does not show up on the GitHub activity chart, which is one of the main reasons campers want this functionality.

[adamisntdead]

I had a version using github repos complete but I have to rewrite for the react codebase

Sent from my iPhone

On 13 Oct 2016, at 23:08, Quincy Larson [email protected] wrote:

@marhyorh this is easier to integrate, but it does not show up on the GitHub activity chart, which is one of the main reasons campers want this functionality.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[QuincyLarson]

@adamisntdead yes - this should be a one-time change. We are working hard to finalize the React branch. Thanks for your help working on this commonly requested feature!