feat: add support for fetching a greeting CTA as part of the update flow MONGOSH-1897

[nirinchev]

This is an early POC of an approach to fetch a greeting CTA via the versions json. The proposed design adds support for reading a cta field in the version objects:

 {
   "version": [
     {
       "version": "1.2.3",
       "downloads": [ ... ],
+      "cta": {
+        "chunks": [
+          { "text": "Fill out our survey ", "style": "bold" }
+          { "text": "https://mongodb.com/survey", "style": "mongosh:uri" }
+        ]
+      }
     }
   ]
 }

These are optional and nothing will be displayed if they're not present. If they are present and the version matches the current version, we'll format the chunks with their corresponding styles and display the message as part of the greeting.

Additionally, we add the following to the update-metadata.json:

 {
     "updateURL": "https://downloads.mongodb.com/compass/mongosh.json",
     "lastChecked": 1730881696340,
     "etag": "\"7f84f631518c4872e3e469c765d1eb03\"",
     "latestKnownMongoshVersion": "1.2.3",
+    "cta": {
+        "1.2.3-alpha.1": {
+           "chunks": [
+                { "text": "This is an alpha version! Use with caution!", "style": "bold" }
+            ]
+        },
+        "1.2.3": {
+           "chunks": [
+                { "text": "This is a stable version and very reliable!", "style": "bold" }
+            ]
+        },
+    }
 }

The greeting CTA for the current version based on package.json will be picked, but locally we're saving both the current and the latest version's CTAs to make it readily available once the user upgrades.

[addaleax]

I think this is the only step in this approach that I don't fully follow – is the idea that we'd locally run the update-cta command? How would we get the credentials to access the relevant S3 bucket?

We're definitely moving towards a world in which less and less access will be given to individual developers' machines, so I don't think this is something we could easily do, and we may just need to fall back to a variant in which we update the CTA entries along with the version feed during releases only – I think that would be okay though, we're generally free to do mongosh releases whenever necessary.

(In the future, we'll need to make sure that even this kind of flow where we update an existing file in S3 as part of the releases is supported – see e.g. https://jira.mongodb.org/browse/WRITING-16730)

[nirinchev]

I was hoping we could decouple releases from CTA updates. I had the following in mind - let me know how it sounds:

1. Updates are published when cta.conf.js is updated. This will have to go through the normal PR flow of accepting changes.
2. When the change is merged into main, a github action triggers that has access to the S3 credentials through environment secrets and runs the update-cta command.
3. The secrets are stored in an environment - let's say "production" - that will have protection rules configured, which means the deployment will be paused until the protection rules are satisfied (e.g. approval required by specified people/wait specified number of hours).

[addaleax]

a github action triggers that has access to the S3 credentials through environment secrets and runs the update-cta command.

We can do that but I think we'd be going for Evergreen rather than GHA here? That's the only platform I'd really expect to be available to access release infrastructure in the long run. I think we'd encounter some resistance if we wanted to put downloads.mongodb.com secrets into another CI environment

[nirinchev]

We could sort it out - my personal preference is towards GHA and we already have a handful of products being signed and released with secrets stored in GHA, as well as all our code being hosted by github. That being said, if there's a strong desire to only do that on evergreen, we could work with those limitations - the important part here is that the flow of publishing CTA updates happens on CI and in a somewhat automated and reviewable fashion.