Add an S3 publish action

[t4k]

Uploads built assets to S3 and invalidates the matching CloudFront paths, authenticating with OIDC so no long-lived AWS keys exist anywhere.

Replaces the per-repository publish_to_s3.bash and invalidate_cdn.bash scripts, which needed an uncommitted media.env to exist on someone's machine.

What it does differently from the scripts it replaces

• The invalidation is scoped to the project's prefix. The old script invalidated /*, which charged for and discarded every other project's cached objects in the same distribution.
• It refuses to publish an empty or missing source directory. A build that "succeeds" into nothing would otherwise leave the CDN serving stale objects with no signal.
• Content types are set explicitly per extension. The AWS CLI's guess omits the charset and has changed between versions; publish_to_s3.bash set text/javascript and text/css with charset=utf-8, and the live objects carry those. Replacing it should not quietly change them.
• The job summary links every published file. S3 website endpoints serve no directory listing — a URL ending in / returns 404 rather than an index — so there is no parent URL to link. Set public-base-url to turn the file list into links.

Things worth knowing before merging

• It uses cp, not sync --delete. The CL-web-components prefix holds a fonts/ directory that exists in no repository — three woff files that page.tmpl and the footer component load. A delete-enabled sync would remove them and nothing would put them back.
• --acl public-read is kept, and the reason is in the script: the media bucket is in legacy ObjectWriter mode with no bucket policy, so public read comes entirely from per-object ACLs. Removing the need for it means adding a bucket policy first, verifying the CDN still serves, then setting BucketOwnerEnforced — in that order, or every project on the distribution goes down.
• The calling job must declare permissions: id-token: write. A composite action cannot.
• The role's trust policy must name the calling repository's subject claim, which is repo-specific. A role that works for one repository will not work for another until an entry is added.

Testing

CI covers the argument handling and both guards. It holds no AWS credentials, and should not — the end-to-end path was exercised from a fork against separate test resources, with dry_run reporting the same destinations the old script wrote to:

==> dist -> s3://***/cl-webcomponents/
==> css  -> s3://***/cl-webcomponents/css/
==> would invalidate /cl-webcomponents/* on ***

Those paths match publish_to_s3.bash exactly: root bundles to the prefix root, CSS under css/.

Once this merges and v1 moves, I'll re-run that dry run against the released action before the CL-web-components caller is opened.

🤖 Generated with Claude Code