cargo:smartdeploy

This goal would do what ever is necessary to take the current artifact and get
it deployed and running in the container. So, if the container is not running,
it would start it, if the artifact is not deployed, it would deploy it. If the
artifact is already deployed but is stale, it would undeploy the old one and
deploy the new one.

If the container is already running and the artifact is already deployed and up-
to-date, then it would do nothing!

The goal of staleness checking would be to skip a redeployment when one can be certain that it is not needed. In the worst case, if you cannot be certain, then it would go ahead and redeploy. I think an occasional ("unnecessary") redeployment is better than thinking something got redeployed when it was actually skipped. Nut considering that for large applications, redeployments can sometimes take a very long time, skipping an unneeded redeployment would be very useful.

Staleness detection I would guess would be done through a timestamp/file size/checksum comparison. If the current artifact can be determined to be the same as the one used for the last deployment (what is currently running), then skip the deployment (with an appropriate INFO message). Maybe something like a special 'touch file' can be used. If some form of checksum or the filesize were stored in the touch file, then even if the timestamps were the different, one could still confirm that the artifact has changed before redeploying.

However, this approach (with some extra-deployment touch files possibly having checksums) does not accomodate good interoperability with other forms of deployment (e.g., manual deployment that does not update the touch file). So there might have to be fallback of some sort. The staleness of the touchfile itself might have to be checked.

The algorithm would be something along the lines of:
1) determine what to compare with:
if touch file exists {
if is it older than timestamp of deployed directory

{ use fallback -- timestamp of deployed directory (?) }

else

{ parse touch file to get deployed timestamp, filesize, checksum }

} else

{ use fallback -- timestamp of deployed directory (?) }

2) if we have deployed checksum, compare with current artifact; if they are the same, skip re-deployment
3) compare timestamps;
4) if we have deployed filesize

{ compare filesizes if timestamps are the same AND filesizes are the same, skip re-deployment }

5) if timestamps are the same: skip re-deployment (is this enough certainly? this might kick in for an intermediately issued manual deploy)
6) deploy and update touch file (with deployed artifact filesize and/or checksum)