Basically :
- When you push a Dockerfile, all the pipeline will be triggered, except the push-prod stage.
- When you push a docker-compose, only the security checks will be done, based on the latest built image. It is in that case useless to rebuild the image!
- When you push a clair-whitelist, only the Clair stage will be done. Same reason as above.
- When you push something else (e.g. a config file), you may trigger any step you want by hand, for flexibility. No more dumb "Trigger CI" commits!
- When you push something else (not in a pica-* folder), nothing happens and you cannot trigger anything. This is expected.

The pipeline will automatically build the image whenever some files are changed.

But for some tasks, you may want to enable certain stages manually.
This is what this commit does.

Until now, a unique image was built and pushed for each commit, tagged with the commit number.
If this has the avantage to identify which commit corresponds to which image, it causes other problems.

For example, if the pipeline fails because of an approved CVE, you may just want to whitelist the CVE.
Problem : you will need to rebuild the entire image even if nothing has changed, because the "clair" stage tries to pull the image with the current commit id in tag.

So the following was done :
- As soon as an image in successfully built, push it to the registry. OVERWRITE THE OLD IMAGE. This is ok.
- Now, you rebuild the image ONLY if the Dockerfile has changed.
- You run Clair if the clair-whitelist.yml (or Dockerfile, docker-compose) has changed. "clair" stage will be able to find the last previously built image. This is good, no need to build again ! Faster.
- Remove the push-test stage : already done earlier.

See https://www.dokuwiki.org/install:unused_files for more informations

As explained on [this page](https://www.dokuwiki.org/install:upgrade), as the Dokuwiki files (PHP...) and user pages are "mixed" in the same directory, it is better to get the new Dokuwiki version in a separate directory, and then to copy the files.

This way, we won't have conflicts between old volumes and new files in the image. It is safer.

Thanks to the excellent trick here : http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/