Before every transfer there is a list. It answers the question you have before the click — what happens next?
The changes
Before the first diff, this says what to do: build or refresh.
The card Changes compares the current build with what last went to this target, and splits into three groups: New, Changed, Removed.
If it says “No diff computed yet”, the comparison is missing: build first, or Refresh diff. If it says “No changes since the last deploy”, there is nothing to do.
How reliable that list is depends on the method — see 6.4. rsync asks the server; SFTP, FTP and the folder compare against a local list.
Upload everything again
The button for when the local list no longer holds. It discards what QuartzControl last sent to this target — after which the preview offers the whole build again.
It is meant for everything QuartzControl cannot see: a file deleted on the server by hand, an aborted transfer, a restore by the provider.
Delete removed files in the target too
A switch on the target. For good reason not a default but a decision:
- On — whatever disappears from the build disappears on the server too. Tidy, but dangerous if something else lives there.
- Off — removed files stay. QuartzControl then adds that they keep being counted.
Never publish
One path per line, on the target. Whatever matches is not transferred and not touched when deleting —
.htaccess, say, or a stats/ folder the provider fills itself.
Not to be confused with the exclusions under Configuration: those keep a note from becoming a page at all. These keep a built file from reaching the server.
The output folder
It is the same as under Preview & build — what is uploaded is what lies there. Change it in either place and you change it in both.
The confirmation
Before transferring, QuartzControl asks with numbers:
Publish to …?
34 file(s) will be uploaded, 2 file(s) will be deleted on the server.
For a branch target it says instead the sentence that matters: the branch is replaced wholesale by the current build.