Bump ubuntu from 22.04 to 24.04 in /workspaces/desktop

[dependabot]

Bumps ubuntu from 22.04 to 24.04.

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

All images

Image	Platform	Old Size	New Size	Change
prairielearn/executor:bbb2a148ccc987588157219622b471e320d07857	null	1627.45 MB	1627.45 MB	0.00%
prairielearn/prairielearn:bbb2a148ccc987588157219622b471e320d07857	linux/amd64	1627.44 MB	1627.45 MB	0.00%
prairielearn/workspace-desktop:bbb2a148ccc987588157219622b471e320d07857	linux/amd64	717.79 MB	835.92 MB	16.46%
prairielearn/workspace-desktop:bbb2a148ccc987588157219622b471e320d07857	linux/arm64	695.92 MB	814.42 MB	17.03%

[jonatanschroeder]

Tested locally and it seems to work as expected. Should wait to merge until after the finals season to avoid breaking any existing course.

[nwalters512]

Something I've been noodling over: should we find a way to publish images with specific tags? e.g. we could have been publishing master as prairielearn/workspace-desktop:ubuntu-22.04, and then publish future versions based on these changes as prairielearn/workspace-desktop:ubuntu-24.04 (as well as :latest). This more closely matches how people generally tagging Docker images, and would allow instructors to be deliberate in their choice between the bleeding edge with :latest and patches to a particular version with :ubuntu-24.04 (or whatever other versions happen to exist).

I don't think we have to do that before landing this PR, just food for thought.

[jonatanschroeder]

Something I've been noodling over: should we find a way to publish images with specific tags? e.g. we could have been publishing master as prairielearn/workspace-desktop:ubuntu-22.04, and then publish future versions based on these changes as prairielearn/workspace-desktop:ubuntu-24.04 (as well as :latest). This more closely matches how people generally tagging Docker images, and would allow instructors to be deliberate in their choice between the bleeding edge with :latest and patches to a particular version with :ubuntu-24.04 (or whatever other versions happen to exist).

I don't think we have to do that before landing this PR, just food for thought.

I'm on board with that, assuming there's tooling for it, though we might want to consider what happens if we find a bug that affects multiple tags (or only a previous tag). Do we support the older versions? Also, would it be a better option to move graders and workspaces to separate repos?

[nwalters512]

I'm on board with that, assuming there's tooling for it

We'll of course need to build such tooling 🙂

Do we support the older versions?

I don't think we've ever patched an older version of a workspace/grader. Even if we wanted to do that, we haven't had a way to do that in the past (what would we tag the new old version as?).

If we're talking about the hypothetical future where we want to re-tag an older version... I think we could do that in exceptional circumstances, but most of the time I think we'd just tell folks to use the latest image. If we really wanted to optimize for that case, I'd suggest that we do something like what the Node Docker image repo does and place each version/OS combination into its own directory, so we could always go back and modify old images.

Also, would it be a better option to move graders and workspaces to separate repos?

IMO we should keep all core workspaces in the source tree for now.