Ah yes, apologies. That makes sense!
An Engineer is digging into this as we type! We aren’t sure what’s going on exactly, but when I have details i’ll update this thread.
Thanks heaps to you and your team for looking into this!
In the meantime, are the engineers able to give insight to how the Work in Repl link works? Namely, I noticed the URL target of this button having the following format:
I’m particularly intrigued by the the
assignment_repo_id=12345678 parameter. Is there a way from GitHub Classroom (or the GitHub Organization linked to the classroom) allowing us to find out what the student’s
assignment_repo_id is? I believe that would at least allow us to manually add this button as a worst-case hack – and then the issue is “fixed” for the student. I don’t think it’s some secret (since it is eventually made accessible once the Repl button is put in place). I suspect this parameter is used by Repl in some way to check it is allowed to clone a private copy of the repository.
The reason I ask, is because I’m particularly worried about the future of this happening again. At least with this available, we can guide students to manually add in the button themselves. By having this
assignment_repo_id visible to students (or at least teachers), it would be a fantastic fallback solution in case some other bug happens in the future causing the button not to appear. Then we just need to advise students something along the lines of “edit your README.md file, copy-paste this bit of code, replace this number with your
assignment_repo_id found in XYZ”.
This is my first semester using GitHub Classroom + Repl integration. It has been a game changer for me in the teaching of early programming courses. I love it, and students seem to love it. I’m planning to completely revamp my teaching approach next year, just because of what this allows. This little backup option would give me the reassurance, although I don’t know where you’d make it visible (i.e. GitHub Classroom or GitHub itself).
In case this is of help to other teachers, these are the instructions I have shared with my students to temporarily work on their assignments until the problem is fixed. Feel free to copy/paste/edit as you see fit for your course:
Linking Repl to your GitHub repo
- If you haven’t already done so, go to https://education.github.com/pack, click on the Get your pack button. Complete the form, etc. You will see on this page how this will give you 3-months free of “Hacker” price plan for repl.it. You need the Hacker plan so that you can create private Repls in repl.it.
- It is very important that you make all your Repls private! It’s your responsibility to keep your code private, otherwise someone might copy it and you’ll be picked up as a kind and willing person that likes sharing their code. Big no no.
- Go to GitHub.com, go to your cloned repo (i.e. the one with the missing Work in Repl button).
- From there, click on the green Code button, and grab the URL you see there.
- Once you have the Hacker Repl account, go to repl.it.
- Go to My Repls
- Click the blue “+” button, at the top right.
- Click on the Import from GitHub tab.
- Paste the URL of the GitHub repo you copied from above.
- Click on the “Import from GitHub button”
- It will then do the import.
- IMPORTANT: go to My repls again, and see that your assignment (which will have an entry now) is shown as private next to its name, in the My repls list. Keep it private. If you can’t make it private, it’s because you haven’t made a Hacker account for Repl (remember, it’s free for 3 months – more than enough for the rest of this course).
Optional extra step (you still need to do the steps above first)
After you have created the Repl via the “Import from GitHub” step, you can still manually add in the “Work in Repl” button to your GitHub README.md file (this isn’t essential, as you can still just go to repl.it directly). But anyway, here’s how to do it:
- I recommend you do this from Repl.it (rather than directly in GitHub – because then you would have to do a “pull” and that might cause you a merge conflict or something depending on what other changes you have made via Repl).
- Copy the following:
[![Work in Repl.it](https://classroom.github.com/assets/work-in-replit-14baed9a392b3a25080506f3b7b6d57f295ec2978f6f33ec97e36a161684cbe9.svg)]( REPLACE_ME )
- Now go to the new Repl (i.e. inside repl.it) for the assignment that you have just manually made a Repl for (i.e. the one that is missing the Repl button).
- Paste the part you copied just above.
- Keep the content in the
[...], but delete the
( ... ).
- Copy the URL that appears in the browser’s address bar of the current Repl (i.e. the one you want to work on). Paste this URL inside the
(...)instead of the
REPLACE_ME. Make sure you keep the parenthesis.
- Go to the Repl Version control section, and do a commit and push.
- Go to github.com to your new assignment’s repo, and you should see the Repl button there. Click it, it should take you to the Repl you just created
I’ve been waiting on a fix for this a few days as well. Extra details: when an assignment is created (i.e., template repo cloned), there are a number of commits that take place to set things up. This includes Repl.It integration (commit that updates the README file), setting up the autograding, etc.
The really problematic part is that there are a pair of empty commits that are on repeat, and they trigger the CI/CD to kick in. There seems to be some step in the process that is creating an infinite loop, and as a result it just eats up the monthly minutes.
I may need to resort to forgoing the CI/CD for this assignment (essentially there to assert their submission is valid and complete), and use the instructions above for the students to gain Repl.It access (thanks @nasuoa !).
If they want a detailed case study, let me know. The behaviour is absolutely consistent with my assignment right now (and I’ve unshared the link with the class so there isn’t several clones created).
A new strategy that seems to work reliably now: have students click this link (on the page that opens when they click the assignment link)
It forces the remaining commits to be made on the repository (thus adding the Repl.It button) and stops the infinite loop of empty commits if you have auto-grading installed.
Thank you, @haz! I just tried this and it works for me. It’s a little messy because it’s an extra click and isn’t especially clear to students what they’re clicking, but it does the job. Much appreciated. (That web page when they click the assignment link looks different than it used to, doesn’t it? Did that just change?)
It seems so, ya. They mentioned it in another thread about the repo creation being locked up. Seems like a backstop measure while they figure out what the deuce is going on with the buggy sequence of commits.
Thank you @haz !
It would be great to get some official word on what’s going on with this (fairly major, it would seem) bug. Any takers?
In the meantime, just a heads up for instructors – students may face odd push/pull tension with Repl.It and students that don’t do the “update” advice above before editing. The empty commits continue on the GitHub side, and then there’s a (benign) clash in the version control of the created Repl.It. Student will need to pull (which seems buggy, so has to be done multiple times) and then commit+push on Repl.It.
It’s not worth explaining all this to a full class – out of 350 it’s only been brought to my attention once (though it may increase as the assignment deadline inches closer). My hunch is that they can only get into this state if they create the Repl.It manually on a repo that is still in it’s funny state of not having the button available (and commits continually coming in).
I’ve had to disable the auto-grading, since (even with the education bump to 3k) it hit the limit of minutes very quickly. I was only using it for students to know their submissions were formatted correctly and complete, but this may be a much bigger issue for fully graded assignments.
Yeah, that’s the problem with the current “fix”. It seems that repl.it doesn’t seem to recognize changes made in the GitHub repo, and doesn’t offer to “pull” (although it used to in the past – so this might be tied to the same bug). Here’s what I advised my students to make sure they double/triple check there won’t be any merge conflicts:
Please read the instructions carefully if you have already made changes to your code in Repl, to avoid losing any work!!
- This first step is very important. If you have already modified your code in Repl (i.e. using the solution below where you made your own Repl manually and linked it to your GitHub repo manually), then make sure you do a Commit and push from Repl and send all your changes to GitHub to avoid losing anything!
- Go to GitHub.com and make sure your commit was registered! If not, don’t progress until you make sure your changes were registered!
- Once you see your commits in github.com, go to Canvas and click again on the invitation link for the relevant assignment/lab etc that is missing the Repl button.
- When you click the button, it will tell you “You’re ready to go!” etc.
- At the very bottom, you will see something like:
- "We’ve configured the repository associated with this assignment (update)"
- Click once on the update link.
- Now go refresh your GitHub page, and you should see the Work in Repl button again!
- At the very bottom, you will see something like:
You’re still not done. The next step is still important. Even though GitHub has this button, ultimately the Repl project doesn’t have the latest changes. It is important to make sure Repl sees the changes, to avoid it later having a merge conflict.
- Go to the terminal on the right hand side (the black rectangle area). Type
git pull, then enter your GitHub username when prompted, and then enter your GitHub password when prompted. It should then update your README file inside Repl (i.e your button is now visible there). Done.
- As an extra precaution to make sure you’re all good. If you want to be extra sure before you do too much work (I recommend this), go make a minor change anywhere in your Repl project and then do another “Commit and push” from within Repl. Go check it’s visible in github.com.
- Go to the terminal on the right hand side (the black rectangle area). Type
I just noticed that the user interface changed again.
When a student visits a GitHub Classroom link and creates a repository, as usual they then see a page with the text “You are ready to go!”, which contains a link to the repository that was created. What’s new is that this page no longer contains an “update” link as described above. Now, it contains a “Work in Repl.it” button. Click that, and it creates the repl. So it appears that the students get one chance to create the repl, which is instantly after they create the repository. It seems to work, though it’s a bummer that if the students miss the link, they’ve missed their chance.
Oh, dear…that “update” link was a fail-safe for other bugs too :’-(
I had somehow missed this update on this post and am eager to hear more here. The hope was that the new button would be there as an opportunity to see the missing button but it sounds like it might be causing more harm than good. Is that right? I’d love to make it work great for everyone.
Hi @jeffrafter, thanks for the followup. The real challenge here isn’t so much the location of that “Work in Repl.it button,” but the fact that the repository gets commits (with the “Work in Repl.it” button in the README.md) that are sometimes added much later. If that has been fixed, then the rest of this becomes fairly moot. If it hasn’t… that’s a pretty major user interface difficulty that I don’t see locations of buttons resolving.
I think the other difficulty this last fall was the rapidly changing user interface without warning or explanation. It made it very hard for me to support students. I would create an assignment with a detailed explanation as to the steps that they should follow… and then half the class would see a different interface depending on when they started the activity. Of course, things need to evolve over time, but it was difficult for me to support when changes were coming fast and furious and there was no documentation or other mechanism for me to try to understand what was going on. That was the main point I probably failed to make clear in my earlier post.
GitHub Classroom is an amazing tool that I really appreciate, and I know it’s an enormous amount of work to keep something like this moving. Kudos to GitHub for doing that! But if it can’t have reliable behavior, that becomes very difficult to support as a teacher, especially when students are working remotely and asynchronously. In my opinion, a reliable and understandable interface is what matters, rather than quibbling over where the button should land.
That makes a lot of sense. Under-the-hood GitHub Classroom has been changing pretty dramatically. The biggest changes came over the summer and more recently we have been working to implement some of the last foundational pieces that will ultimately allow for better workflows (needing fewer workarounds) and more tools for teachers and students. We miss the mark sometimes in rushing toward that future and for that I am very sorry. Teaching git and GitHub is already hard enough that we shouldn’t be giving you a moving target!
I agree that where the button lives is less important from an experience perspective (as long as it is consistent and easy for students to find and use) than the possibility that commits are added which lead to merge conflicts. Merge conflicts are one of the hardest things to deal with early on and if there is a workflow here that is leading to them I would love for us to adjust it so that doesn’t happen. If you have a scenario I could try out we can think through some alternatives there (for example if the merge conflict is coming because of an autograding commit, we could possibly delay that).
It’s a broader issue that is unique to education-based software. If GH Classroom was an on-prem project, we (as instructors) would all grab the latest stable release at some point prior to the semester, and update only for bug fixes. Then repeat with the latest and greatest for the next semester if/when we have time to learn what’s new, update the instructions, etc.
Features coming fast & furious, as well-intended as they may be, just destroys any ability to use it reliably in the classroom setting.
Again, it’s kind of an issue unique to the education domain; many of us being on this 4-month rotation. Given that it isn’t a project or service we install ourselves, perhaps a major feature push should be in the direction of allowing us instructors to “lock-in” for a semester when a classroom is created?
Sorry to jump in but this really resonates with my experience. I don’t know how feasible it would be, but I would love it if we could lock into a specific feature set. It’s really frustrating when things change half-way through a course.