[prebuilds] Automatically disable prebuilds for projects without active Workspace usage

[easyCZ]

Is your feature request related to a problem? Please describe

In some instances, users configure Gitpod for a repository but do not actively start workspaces to develop in Gitpod.

Because of our prebuilds - optimization to get you to run workspaces faster, we continue to react to pushes to the repository and create prebuilds. However, these prebuilds are not useful as the users do not actively use gitpod to develop these.

In this scenario, we should consider reduce the number of prebuilds triggered from these repositories. Some options for doing this:

• disable prebuilds entirely if no workpsace started in the last 7 days
• Limit prebuilds to main only (and once a day) if no workspace started in 7 days

With this change, we need to strike the balance of convenience for the user and fairness in a multi-tenant system.

Originally raised by @kylos101.

[jankeromnes]

Many thanks @easyCZ for filing this issue! 💯 I'm very much in favour of this.

if no workpsace started in the last 7 days

• I wonder if 7 days is maybe a bit too short as a checking period (e.g. imagine a project with just a few developers, and they all happen to take a week of holidays at the same time -- disabling their prebuilds might be a bit too disruptive). How about 3 months?

• Also, I wonder whether it makes sense to check for "did any workspace start for this project", or if we should more precisely look at "did any of the prebuilds get used as a base or a workspace" (somewhat similar, but I'd argue we're looking precisely for prebuilds that are 100% unused here -- although, looking for projects that are 100% unused could also be interesting, e.g. if we want to garbage collect projects one day? 🤔)

---

As for a technical approach, I guess we could implement a uninstallAutomatedPrebuilds method in RepositoryService, similar to:

gitpod/components/server/src/repohost/repo-service.ts

Line 20 in 2f0b946

async installAutomatedPrebuilds(user: User, cloneUrl: string): Promise<void> {

Then, I think we could possibly add another method to our GarbageCollector, that checks for projects (cloneURLs) which have prebuilds in the past 3 months, but none of these recent prebuilds were actually used to start a workspace, then just disable prebuilds for that project.

gitpod/components/server/src/workspace/garbage-collector.ts

Lines 40 to 49 in 2f0b946

	public async garbageCollectWorkspacesIfLeader() {
	if (await this.leaderQuorum.areWeLeader()) {
	log.info("wsgc: we're leading the quorum. Collecting old workspaces");
	this.softDeleteOldWorkspaces().catch((err) => log.error("wsgc: error during soft-deletion", err));
	this.deleteWorkspaceContentAfterRetentionPeriod().catch((err) =>
	log.error("wsgc: error during content deletion", err),
	);
	this.deleteOldPrebuilds().catch((err) => log.error("wsgc: error during prebuild deletion", err));
	}
	}

[jankeromnes]

See also research issue (internal)

[kylos101]

@jankeromnes @easyCZ Another dimension to consider is tuning how aggressively we stop doing prebuilds based on the plan for the user. For example, we might want to be clean-up more aggressively for free plans, but, less aggressively with pay plans.

[kylos101]

@atduarte for awareness

[kylos101]

@easyCZ I seem to recall this (or something like it) being socialized recently, and just wanted to bump this issue for awareness. 👋 Hope you're well!

[jankeromnes]

Spontaneously jumping on this issue, as it seems important and compelling. 😁

EDIT: See also internal thread discussing implementation of a fix.