[mblow]

The overview page had not been updated since 2.0.0. Refresh it against the 2.2.1 documentation and add tooling to regenerate its screenshots.

Overview (generate/resources/enterprise-analytics/README.md):

• Drop the hardcoded :2.0.0 image tag from all docker run commands. The README is copied byte-identically into every version directory and any version's build can overwrite the Docker Hub description, so a pinned tag cannot be correct everywhere. This matches couchbase-server, sync-gateway and couchbase-edge-server, none of which pin a version.
• Sync the feature list with the docs, and add the 2.1/2.2 headline features: Azure Blob Storage and GCS as storage layers, Apache Iceberg, Oracle and SQL Server CDC, Index Advisor, JWT authentication and the async REST API. Version-gated entries are marked so the text stays accurate in the older version directories.
• Fix the S3Mock bucket env var: initialBuckets was renamed to COM_ADOBE_TESTING_S3MOCK_STORE_INITIAL_BUCKETS. Against a current adobe/s3mock the old name silently creates no bucket.
• Correct the volume path from /opt/enterprise-analytics/var/lib/couchbase/data to /opt/enterprise-analytics/var, which is what the image declares as VOLUME and what the docs recommend mapping. Mounting only .../data loses the cluster configuration when the container is recreated.
• Complete the ports table: the image also exposes 9123, 11207, 11210 and 11280, all of which the docs classify as client-to-node.
• Add --partitions 16 to setting-enterprise-analytics; the default of 128 is needless overhead for a development cluster.
• Note which blob storage settings are fixed at cluster setup (the storage scheme and the number of storage partitions) and which can be changed afterwards, and list the azblob and gs schemes.
• Add a container requirements section covering the AVX2 requirement on x86_64 (the entrypoint aborts without it), RAM and disk minimums, multi-arch availability and the production ulimits.
• Add an Additional References section and link the license properly.

Screenshots (generate/screenshots):

• Add robot-ea, which drives the 2.2.1 setup wizard and console against a S3Mock backend and captures the seven images the overview embeds. There was previously no automation for Enterprise Analytics; the published images were manual captures that still showed 2.0.0 and included browser chrome.
• Build on mcr.microsoft.com/playwright, which is multi-arch, so the robot runs natively on arm64 as well as amd64.
• Document both robots, and the upload and CloudFront invalidation steps.

The sample query now counts airlines rather than airports so that the screenshot agrees with the surrounding text.

Only the 2.2.0 and 2.2.1 deployed copies of the overview are updated. Note that deployReadme runs regardless of whether a Dockerfile already exists, so go generate will also rewrite the 2.0.0, 2.1.0 and 2.1.1 copies, and those of other products whose deployed copies have drifted from source; those were reverted to keep this change scoped.

[mblow]

Hi @mhocouchbase, remind me how I can get the images updated on cloudfront, and if that needs to happen before or after merging this PR. I have the images generated locally.

[mhocouchbase]

Hi @mhocouchbase, remind me how I can get the images updated on cloudfront, and if that needs to happen before or after merging this PR. I have the images generated locally.

They are under a s3 bucket, s3://cb-dockerhub-screenshots-origin. Do you have access to upload to this? Also need to create a cloudfront invalidation if same files are changed. I don't know if there is a jenkins job for this.

[mblow]

They are under a s3 bucket, s3://cb-dockerhub-screenshots-origin. Do you have access to upload to this? Also need to create a cloudfront invalidation if same files are changed. I don't know if there is a jenkins job for this.

Hi @mhocouchbase, I can rework to use unique filenames to avoid having the to do the invalidation- since this is for a new version. It sounds like this would be easier- let me know,

[mhocouchbase]

Hi @mhocouchbase, I can rework to use unique filenames to avoid having the to do the invalidation- since this is for a new version. It sounds like this would be easier- let me know,

I don't have a preference to be honest. Invalidation is not difficult.
Do you think this is going to happen often, i.e. every release or every major/minor release? Currently, the files are under s3://cb-dockerhub-screenshots-origin/ea. Maybe create a release specific folder s3://cb-dockerhub-screenshots-origin/ea-2.2.x?