Option to reset to tutorial state

[ShMcK]

There is potential that users may go "off the rails" in a tutorial.

In this case, they should still be able to jump into a stable version of the current step. As the tutorials run on git, it's possible to load the stable state by running something like a git reset --hard HEAD that targets a specific commit.

Some issues to consider:

• this would destroy the users commits, which may have already synced remotely, leading to merge conflicts when pushing

[ShMcK]

I think there are a few ways reset could work:

1. Reset to last passing test

In most cases, this should help the user get back on track - but there is potential that tests may be passing while the user is still "off the rails".

2. Reset to a timeline based on the tutorial creators solutions

This would be a kind of hard reset that destroys the users timeline but ensures that they have a working copy.

[ShMcK]

May also want to trigger a reset script. Eg. in a SQL based tutorial.

[ShMcK]

I think it may be best to present the user with the options and explain what is happening.

The feature can be implemented in order with 3 parts.

1. Run Reset script

If provided in the tutorial config, run the reset script.

For example, a DB seed script in a SQL tutorial.

config:
  reset:
    command: './scripts/reset.sh'

What if a reset script needs to change later in a tutorial?

If a reset script needs to change at later levels, it can be updated within the git timeline.

2. Reset to last passing test

a. find the last successful test commit hash
b. git reset --hard <commit_hash>

To capture the last commit_hash, we could store the last commit_hash in:
a. in local memory (fails in case of a restart)
b. local storage (in case of a restart)
c. nowhere - just search for it on-demand within the config

Option c. strikes me as the simplest.

3. Reset to working timeline

a. find the last successful test commit hash
b. git clone <repo/branch> coderoad
c. git reset --hard <commit_hash>

In this case, the entire solution branch would be loaded, then trimmed down with a reset.

It may pose problems later if tutorials are made private.

[moT01]

I think it may be best to present the user with the options and explain what is happening.

What type of options were you thinking of? I think it's best not to give them options if we can avoid it. It can create confusion and more they have to think about.

2. Reset to last passing test

I would avoid the local storage solutions - like you said, that fails if there's a restart. Also, the "last passing test" wouldn't include the solution from that test (if there is one), would it? I'm trying to think of a case with subtasks, but it wouldn't work there since nothing likely would be committed.

Wouldn't a git reset --hard work for most things? That should take them back to what they had at the start of the lesson - as long at they aren't messing around with the git stuff. Course, that wouldn't work for SQL or bash.

3. Reset to working timeline

Something like this may be a more robust solution since it will rebuild everything. It may be a little slower, but probably the most reliable.

It may pose problems later if tutorials are made private.

There's already problems if a repo is private I believe. Don't they need to be public to "build" and I think to run as well? I had one private at one point and nothing worked if I recall.

[ShMcK]

I wrote this bash script for the reset:

#!/bin/bash

###
### reset git and clone
### 
### note: only tested on mac/linux
###
### Usage:
###  reset <remote> <target_commit_hash>
###
### Options:
###   <remote>               git remote
###   <target_branch>        branch on git remote
###   <target_commit_hash>   git commit on remote/branch

REMOTE=$0
TARGET_BRANCH=$1
TARGET_COMMIT_HASH=$2
TEMP_BRANCH=reset-orphan-branch

# verifications

# TODO: verify params are included

# verify git exists and capture branch
if [ -d .git ] || git rev-parse --git-dir > /dev/null 2>&1; then
    ref=$(git symbolic-ref HEAD 2> /dev/null) || \
    ref=$(git rev-parse --short HEAD 2> /dev/null) || return
    LOCAL_BRANCH=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')
else
    return;
fi

# TODO: verify remote exists or exit

# TODO: verify script has permission to run git 

# TODO: verify commit exists on remote branch or exit

# move to empty branch
echo 'cleaning history...'
git checkout --orphan $TEMP_BRANCH
git stash
git rm -rf .
rm '.gitignore'
git branch -D $LOCAL_BRANCH
git checkout -b $LOCAL_BRANCH

# cleanup old branch
# git branch -D $TEMP_BRANCH

echo 'fetching history...'
git fetch $REMOTE $TARGET_BRANCH
echo 'reloading history...'
git merge $REMOTE/$TARGET_BRANCH

echo 'resetting history...'
git reset --hard $TARGET_COMMIT_HASH

Running the commands in the command line directly works 100%.
But running the script results in git remote permissions errors, since the bash script does not have access.

Looks I can run these commands through node to avoid permissions issues but is a bit harder to test.

[ShMcK]

Closed with #389