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.

[jeanp413]

💯 to deprecate definetely-gp, I created an issue a while ago to at least make it configurable to opt-out #7336 as it was causing me trouble when opening upstream vscode repo
@jldec feel free to close #7336 as a duplicate of this issue

[loujaybee]

Related: #3746

[andreafalzetti]

+1 on deprecating the current behavior, too magical and causes undesired side-effects.

However, also in light of #3746, it would be interesting to discuss how to keep this feature reimplementing it slightly differently.

If I could have a user setting in which I can maintain my own list of repos that are checked fist, I could decide to opt-in for using the community-driven repo or even have my own private repo in which I configure Gitpod for private repos to which I cannot commit the .gitpod.yml.

[axonasif]

Maybe ask the user whether to load a gitpod provided config or not during workspace start?

[Pothulapati]

Hey 👋🏼 ,

With https://github.com/gitpod-io/gitpod/pull/9094/files, We are setting the definitelyGpDisabled option to be true, and thus disabling it by default. Should we update the SAAS and preview environments deployment configs to enable it (i.e setting it to false) as a part of that PR? 🤔

[laushinka]

Should we update the SAAS and preview environments deployment configs to enable it (i.e setting it to false) as a part of that PR? 🤔

@Pothulapati Isn't the SAAS deployment set to false by default already?

[Pothulapati]

Should we update the SAAS and preview environments deployment configs to enable it (i.e setting it to false) as a part of that PR? 🤔

@Pothulapati Isn't the SAAS deployment set to false by default already?

Hmm, Where is it being set? I couldn't find the configuration anywhere and hence the question! If it is already being set explicitly , then the change would go smooth! If not then it will be set to true after it's merged as the installer's default is being changed. 🤔

[stale]

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.

[AlexTugarev]

Reverted in #18306. It should be possible to re-apply the PR with some changes.