Redeploying an unchanged encrypted site, or rolling back, now works

Since the October fix, deploying an unchanged Level 0 site again has worked. Two cases still failed with:

workload already exists with different bytes

Redeploying an unchanged Level 1 or Level 2 site failed, because each build encrypts the site with a fresh secret, so two builds of the same files differ. Rolling back to an earlier deploy failed at any level, because it uploaded a package that was already stored.

From 0.5.0, ee-cdn-cli first asks whether the content is already stored. If it is stored at the same level for your project, the CLI deploys the stored copy and uploads nothing. Redeploys and rollbacks go through, at every level.

Level 1 sites

• You need the key from the first deploy. The CLI deploys the stored copy only with a key that opens it. Pass it with --key, or set EE_CDN_LEVEL1_KEY, as it appears after #key= in your share link. The environment variable keeps the key out of process listings.
• Without that key, the CLI stops and says so. Nothing is deployed.
• The Astro integration uses its key cache. It now saves a build’s key before uploading, so a lost response doesn’t lose the key.
• Your site keeps its first key. The stored copy is what’s served, so links you’ve already shared keep working, and the rebuild’s own key is never printed or used.

Level 2 sites

• The stored copy is reused when its secret is held. Otherwise the CLI uploads as before.

Limits

• From the portal, redeploying an unchanged Level 1 site is still refused.
• Older versions of ee-cdn-cli still upload, and still get the same refusal.

What you need to do

• If you run ee-cdn-cli yourself, update to 0.5.0 or later. For a Level 1 site, keep the key from its first deploy and pass it with --key or EE_CDN_LEVEL1_KEY.
• If you use the Deploy to Evolving Edge CDN Action at @v1, you get it with the next release, which runs 0.5.0. If you’ve pinned an exact release, change it to that one.