search

gitpod-io / gitpod

The developer platform for on-demand cloud development environments to create software faster and more securely.
https://www.gitpod.io
GNU Affero General Public License v3.0
13.01k stars 1.24k forks source link

Epic: Improve versioning and rollout of workspace images #10683

Open loujaybee opened 2 years ago

loujaybee commented 2 years ago

Press Release

Gitpod has now updated all of our managed workspace images. All managed workspace images except workspace-base and workspace-full (the default) are now tied to a specific programming language to avoid unwanted breakages (e.g. workspace-java-17 and NOT workspace-java). Gitpod has deprecated all previously workspace language images that were not tied to a language version. By continuing to use a deprecated image you will no longer receive any further updates or patches. To check whether your image is deprecated, please run gp validate inside your workspace.

Will deprecated images be removed? No, all images will remain on Dockerhub, but will no longer receive updates.

Context

We maintain a set of workspace images to help customers get up and running on Gitpod easier. Currently all new workspaces are created on the latest version of workspace-full, whilst these users are then kept on the latest versions this does mean that workspace starts can break in unpredictable ways. This epic is around improving our user consistency and strategy around workspace images + general discovery of workspace images.

Acceptance Criteria

Related

Click to toggle contents of `code` Right now our workspace images are updated for customers but the release process / way they're updated is not clear. Users aren't always aware they're even using a base image, and get no notifications currently of any changes. We need to investigate how we can better notify users when a base image is going to be updated, and also encouraging users to either take ownership of their own base image, or be fully aware of the implications of using a managed base image from Gitpod. **Challenges:** * **Onboarding** - New users are often not aware of what’s in their base image, as seen in usability testing. * **Workspace image repo documentation #[2187](https://github.com/gitpod-io/website/issues/2187)** - Could be refined for users (e.g. make it easier to point out the custom changes we are making for easier copy / paste). * **Rollout and versioning has friction #[2587](https://github.com/gitpod-io/website/pull/2587)** - Breaking changes to workspace images are hard to communicate and can break users in mysterious ways. This relates to topics of having org or team-wide images. * **Implicit surfacing in the UX** - Unless the user pins to an image, they are implicitly using an image that they can sometimes not be aware of. * **Maintenance** - We should only maintain a restricted number of images, and consider the support cost. Images should align with language pages in docs. **Opportunities** * The docs restructure #[2587](https://github.com/gitpod-io/website/pull/2587) reduces to 5 languages, and introduces a dedicated “workspace” top-level section, we should review and update our image creation documentation following this. Database image support also needs to be discussed. **Option 1: Deprecations process for workspace images** - https://github.com/gitpod-io/gitpod/issues/7537 - Email notifications with advanced warning of a deprecation **Option 2: Ensure users are aware of the base image and ask them to pin explicitly** - Prompt users to pin their workspace base image version, so new versions can be rolled out without breaking users - Notify users that an update has been made, and they should update - Eventually sunset previous versions with sufficient deprecation warning There is a related topic here about versioning and release. However we currently don't have user-pinned versions to base images, but arguably we could. Relates to: CC: @atduarte / @ghuntley
axonasif commented 2 years ago

From what I've seen, many of the users aren't aware of all the workspace images we maintain.

loujaybee commented 2 years ago

@axonasif, yup.

Improved documentation for sure is part. There's also a product design issue here.

david-bakin commented 2 years ago

And please see my comment here - https://github.com/gitpod-io/gitpod/issues/11455#issuecomment-1188368440 - where I suggest looking inside of custom dockerfiles to see if they need to be rebuilt automagically during prebuilds when the container they're based on changes.

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Siddhant-K-code commented 1 year ago

with gp rebuild (#15490, #7671) . We could workspace-images validation also. It could come with file validation step that could check the state of workspace images deprecation/versions :slightly_smiling_face:

Internal Conversation