Hi, @BramDecuypere, you can send us only the file contents for the change file. But each deploy must state all files and checksums included. If this isn’t done, the API wouldn’t know what files were included in that specific deploy.
Our service uses the concept of “atomic deploys”. Each deploy contains all files needed. If you want to roll back to a previous version of the site you can re-publish an old deploy at ay time as we know all the files in that version of the previous deploy.
If you could modify an existing deploy, then the deploys would no longer be atomic and there would be no way to roll back to a previous deploy.
Now, once the checksums and full file list are sent, our API will only ask you to upload new or changed files. If files didn’t change or if they exist in any previous deploys of the site, the API will not request you send them again.
If fact, if a new deploy happens to only include files previously included in other deploys (maybe deploy 4 is a mix of files already included in deploys 1 to 3), after sending the file list and checksums, our API won’t ask you to upload any files because it has them all already from previous deploys.
- by definition all deploys must define all the paths for the files included and the checksums for those files
- deploys are atomic and cannot be changed after deployment
- if only one file changes or is added in a deploy only that one file needs to be sent to the API (but it still needs all checksums even for unchanged files)
So, yes, there is a design decision of “atomic deploys”. It enables being able to publish complete deploys atomically including rollbacks. The same design choice also means that it isn’t possible to modify an existing deploy.
If there are other questions, ask away!