gitpod-io
jammy (Ubuntu 22.04 LTS)- based images
jammy (Ubuntu 22.04 LTS) ~~is coming~~ is just released.
What is the strategy for jammy-based workspace images?
Resources
- https://lists.ubuntu.com/archives/ubuntu-announce/2022-April/000279.html
- The latest update: #197
- also #196
@gitpod-io/engineering-workspace do we have any hard dependency on ubuntu version that might break with this change. Things like existing work so far with K3s in gitpod / tailscale etc?
We can curate a list and then make sure that we test it before releasing related change to the public. Our existing tests are not enough IMO to just merge a base image verion upgrade change.
Prebuild system and underlying Kubernetes should be updated. Details were described in the following comment:
- https://github.com/gitpod-io/workspace-images/pull/814#issuecomment-1108091553
Versioning with Docker image tagging would be helpful to maintain the stack, like ubuntu:focal and ubuntu:jammy (now equivalent to ubuntu:latest). Users should use gitpod/workspace-full:focal and gitpod/workspace-full:jammy instead of gitpod/workspace-full.
@gitpod-io/engineering-workspace do we have any hard dependency on ubuntu version that might break with this change. Things like existing work so far with K3s in gitpod / tailscale etc?
Not that I am aware of.
It would be great if users could start testing with Jammy. Any updates here?
Hi @tnir @ianhellstrom and @david-bakin,
It just so happens that we're updating our documentation to help users create custom images which do not use Gitpod base images. For example, if your workflow cannot use a Gitpod base image, the docs will show customizations that are needed to have a successful image build, as well as a nice development experience in Gitpod. This may also be a good short term solution for you if your workflow requires Jammy.
Also, we plan to publish a version of workspace-full that supports Jammy. It won't be the default base image, but, it'll be available as something likeworkspace-full:jammy.rc0, etc. The reason for this is so that we can use it (to test internally), but also give the community something to test with, too. Once the release candidate is available on Docker Hub, we'll let y'all know.
Finally, after we've tested internally and collected feedback from the community, we'll consider making this generally available as latest.
Let us know if this helps, or if you have any other questions?
cc: @axonasif and @atduarte and @jenting
