Deploying a site whose content hasn't changed no longer fails

Running a deploy a second time with nothing changed used to fail. Re-running a deploy job in CI, or deploying again after a change that didn’t touch the site’s files, was refused with:

workload already exists with different bytes

The builder that packages your site wrote the time of the build into the package. Two builds of the same files therefore got the same content hash but were not the same package, and we refuse an upload whose hash is already stored with different contents. The only way through was to change something in the site.

The builder no longer records the build time. The same files now produce the same package every time, whenever and wherever they are built, so deploying unchanged content again is accepted.

Limits

• The first deploy after this may still be refused, once. If your site hasn’t changed since it was last packaged by the old builder, the stored package and the new one still differ. Deploy any change to the site and it’s settled: unchanged deploys after that are accepted.
• This covers Level 0 sites only. Level 1 and Level 2 sites are encrypted with a fresh secret on every build, so two builds of the same files still differ, and deploying one again unchanged is still refused.
• Rollbacks still fail the same way. Going back to an earlier deploy uploads a package that is already stored, and that is still refused.

Both are known and not fixed yet.

What you need to do

Nothing. ee-cdn-cli downloads the builder for you, so your next deploy uses the new one.