I’ve just tried to open your repo in a new workspace and have got the same issue. It looks like there is something wrong with the docker image that you specified in your .gtipod.yml file, it’s looking for an image in localhost:8080 it looks like, but obviously cannot find it. I don’t know what your image looks like (jelaniwoods/appdev2021-base-rails@sha256:91427ecf043c8cdd8040bbd3626eb9bbbf3bee99d44ed3d1281504f71681d661) but that would be the first clue/place to look at debugging!
Thanks for the update @csweichel. I can create a new workspace after changing the image reference on GitHub, but I’m still unable to open any existing workspaces that are using the digest of the image, which I have many. This means any unsaved git changes are locked in workspaces that no longer open.
We use Gitpod for class, so unless there is a way to download uncommitted changes, we aren’t able to access workspaces that were previously working.
@csweichel While the main issue of being unable to open workspaces was solved, it looks like the image that’s being pulled for the workspace is not respecting the digest and is instead using the latest tag.
For example, the image I referenced before (jelaniwoods/appdev2021-base-rails@sha256:91427ecf043c8cdd8040bbd3626eb9bbbf3bee99d44ed3d1281504f71681d661)
only has ruby 2.7.3 installed while the image with the latest tag only uses Ruby 2.6.6.
Sorry for the inconvenience. We have deployed a fix for this issue. When I open https://github.com/appdev-projects/base-rails/tree/5e42ef0d03bcc267baf7f13b47f3b7f3ad71dc32 in Gitpod now, I see ruby in the correct version.
I just wanted to point out that this issue is still occurring, and we’ve got hundreds of students who are blocked by it right now (during their final project week ). They had already created their workspaces using an image identified by a SHA prior to whatever change is causing the failures, so it would be very inconvenient for them to have to start over with a fresh workspace.
Any updates you can provide would be very helpful! Thanks again,
Assuming you can start workspaces originating from the default (master) branch, I recommend you try a workaround for one student, and if it helps, share with the others who cannot start their workspaces.
The workaround is to have a user (1) download their files from their workspace and (2) add them to git and start a fresh workspace / or start a fresh workspace and copy/paste the files manually.
When creating the new workspace, I assume it would be best to have them create a new branch from master and then open a workspace, but defer to you and @jelaniwoods. For example, I’m not sure if the assignment has students branching from something that is not the default (master) branch.
This video will show you how to download files from a workspace:
Let us know if you’re unable to download files from the stopped workspaces (which are not starting), or are still having trouble?