[WIP] configcat

[mustard-mh]

Description

Related Issue(s)

Fixes #

How to test

With preview env of this PR

• Create a team, and get its team_id
• Configure ConfigCat gitpod_experimental_portsView_enabled key with team_ids labels appended with your team_id
• See if new PortsView works
• Process in new PortsView, see if events in segment reported

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview
• /werft analytics=segment|TEZnsG4QbLSxLfHfNieLYGF4cDwyFWoe

[jeanp413]

what's the a reason to put the key in an env variable? I know the key is public but in general I think is not a good practice to put secrets in env variables and also pollutes the shell environment, is it just to avoid copying it for the different clients that may use it (vscode/jetbrains/supervisor)?

[mustard-mh]

This is how we did with segment. (Even openvscode-server is using server API trackEvent)

gitpod/.werft/jobs/build/installer/installer.ts

Lines 263 to 264 in 867b11f

	exec(`yq w -i ${this.options.installerConfigPath} 'workspace.templates.default.spec.containers.(name==workspace).env[+].name' GITPOD_ANALYTICS_SEGMENT_KEY`);
	exec(`yq w -i ${this.options.installerConfigPath} 'workspace.templates.default.spec.containers.(name==workspace).env.(name==GITPOD_ANALYTICS_SEGMENT_KEY).value' "${this.options.analytics.token}"`);

[jeanp413]

yeah I see that, the same applies to it 🙂

[mustard-mh]

yeah I see that, the same applies to it 🙂

@jeanp413 I thought segment env var in workspace is not used by anyone. Maybe remove it after ask other teams if it affect something.

If we don't want configcat key to exists in env var, where should we put it and other secret in with third-party component?

• 👎 Inside build process will affect Self-Hosted images
• 👎 Inside env leak secret
• 👎 Inside API only make it a little bit harder to leak
• 👍 Ask server to provide API about configcat (experimental) like trackEvent API

[mustard-mh]

As the key is public, I thought it can be ok. ( I see dashboard just use it with a constant value here XD)

For segment's key GITPOD_ANALYTICS_SEGMENT_KEY, it's ok too because its value is refer to Production Untrusted project

gitpod/components/dashboard/src/experiments/client.ts

Lines 34 to 45 in 7dbfa49

	// newProductionConfigCatClient constructs a new ConfigCat client with production configuration.
	function newProductionConfigCatClient(): Client {
	// clientKey is an identifier of our ConfigCat application. It is not a secret.
	const clientKey = "WBLaCPtkjkqKHlHedziE9g/TwAe6YyftEGPnGxVRXd0Ig";
	const client = configcat.createClient(clientKey, {
	logger: configcat.createConsoleLogger(LogLevel.Error),
	pollIntervalSeconds: 60 * 3, // 3 minutes
	maxInitWaitTimeSeconds: 0,
	});
	return new ConfigCatClient(client);
	}

[mustard-mh]

👍 Ask server to provide API about configcat (experimental) like trackEvent API

Should we change plan to add it to server API? It benefits other components like JetBrains Gateway to use it easier. But will take long time to change related codes.

Maybe an issue labels with tech-debt is good for all teams too. (And let go this PR 🙈

cc @akosyakov @jeanp413

[akosyakov]

No we should not go through server for it, but used ConfigCat directly.

[akosyakov]

The good thing about env var is that it is available to all IDEs, so IDE can use it or fallback to non-production hardcoded inside. I think it is alright to continue with env var.

[mustard-mh]

Close as we move configcat config.json into proxy, more detail see issue #12739, and its PR #12756