Epic: Deprecate definitely-gp

[jldec]

Early Gitpod users were given the option of storing their config in https://github.com/gitpod-io/definitely-gp/ instead of in their own repo. This feature is not documented anymore.

Workspaces start by looking for a directory in definitely-gp which matches the repo name, and then use the configuration from that directory. The configuration can include both gitpod.yml and a Dockerfile.

There are several issues with this approach

• False positive repo name matches result in unexpected errors during workspace initialization e.g. see below.
• Depending on framework-specific configuration from another Gitpod-owned repo for workspace starts, creates additional maintenance and software supply chain security burdens.
• References to publicly hosted repos from within Gitpod complicate self-hosted installations on private networks.

See discord discussion

Proposal
Gitpod should deprecate the built-in runtime use of files from definitely-gp for workspace configuration.

A community-driven repo like https://github.com/shaal/awesome-gitpod would be a better way to share best practices of how to configure Gitpod for different frameworks or languages.

If there are significant numbers of repos in use which regulary depend on this capability, we should do this in 2 stages (if the number is small say < 100, we can simply remove the capability immediately):

• Make the deprecation known to current users #9049
• Remove the injection of configurations from definitely-gp from workspace starts. #9050

The length of the deprecation period depends on how heavily used this feature is.

Background

I noticed when opening a repo called kit that the workspace was being initiazlized with pnpm, even though it was configured for npm with a package-lock.json.

• The repo was not configured for gitpod.
• No inferred .gitpod.yml was added inside the workspace, making the source of the errors difficult to work out.

A GitHub search revealed that the init and command tasks were probably coming from here: https://github.com/gitpod-io/definitely-gp/blob/master/kit/.gitpod.yml.

From the inference code here and implementation here it appears that opening a workspace on any repo whose name matches a directory in https://github.com/gitpod-io/definitely-gp will attempt to use the configuration from there.

To reproduce

• Note the existence of https://github.com/gitpod-io/definitely-gp/tree/master/kit
• Try to open the workspace at https://gitpod.io/#https://github.com/gitpod-io/kit

For another example see https://gitpod.io/#https://github.com/gitpod-io/book

[jldec]

@jankeromnes, assigned to you, since you helped review #7383 😃

Unless we can do smarter detection, we should probably remove definitely-gp as a source of inferred configurations.
Not copying those configurations into the repo, also makes it really hard for users to understand what's happening.

cc: @svenefftinge

[jankeromnes]

@jldec A quick fix for this could be to place the "kit" directory in definitely-gp under a "sveltejs" directory, to make the matching more precise.

From past experience, anything with 4 letters or less is prone to false-positive matches, and should be configured as "org/repo", not just "repo".

[jldec]

@jankeromnes

• this does not address other commonly used repo names like 'book' or 'vscode' which will still match
• users are not in control of how this matching works - we simply take their repo name and look for a directory match. I think this is still likely to produce a lot of bad matches unless we make all the directory names really unlikely.
• Even if we rely on users to know how to name their directories in order to get a match, or we document the directory names, I'm not sure this additional magic is worth the security risk of auto-injecting dependency config into workspaces from a repo which is not as tightly controlled as gitpod-io/gitpod.

I would prefer to stop auto-matching on directories in definitely-gp and just document it's existence in our docs so that users can copy and maintain themselves.