Wipe deployment ID and any other Coder-specific information before imaging

[bpmct]

Somehow, all marketplace installs in our telemetry have the same deployment ID. When we are running the 999-cleanup.sh script let's make sure we wipe whatever is being used to persist the deployment_id.

See Slack Context

[hugodutka]

@matifali This still seems to be a problem. I counted 25 distinct deployments on GCP in December with the ID 68aaf8cf-de7f-452f-8f23-32a9ba7fa864. I think this is caused by the fact that we start Coder during the package build here:

packages/files/scripts/014-coder.sh

Line 5 in 2380ea4

systemctl enable --now coder

The deployment ID is generated and saved in the database when Coder first runs. We could fix this by stopping Coder in the cleanup script and then wiping the Postgres data directory. I think it's located at /var/lib/postgresql/<version>/main.

I also noticed that all deployments with the ID 68aaf8cf-de7f-452f-8f23-32a9ba7fa864 are using Coder version v2.3.2+1372bf8. However, there are other deployments with different IDs that have the install source gcp_marketplace, but they are on up-to-date versions like 2.18.

I have two questions:

• Are there multiple ways to install from GCP Marketplace? I'm unsure why people are still installing v2.3.2.
• Is GCP and AWS image publishing automated? Once we make the change, is publishing it as simple as committing to main, or are there any extra steps?

[matifali]

Is GCP and AWS image publishing automated? Once we make the change, is publishing it as simple as committing to main, or are there any extra steps?

AWS is automated but GCP needs to be manually published. Building AMI images is automated for both.

Are there multiple ways to install from GCP Marketplace? I'm unsure why people are still installing v2.3.2.

No. But I guess we may have both the new and previous listings. And maybe the previous listing is stuck at v2.3.2. We need to check with partnerships to verify that and remove older listings from the marketplace.