Cache Docker images about gitness HOT 7 CLOSED

As a part-solution #80 can work, but it's a little robust way.

from gitness.

I guess this is the other part of the matrix-builds, namely the paralellize one single build part. The setup would have to run once for all, and then each part of the build could run in a different container. Actually, the docker cache would care of that. The build section could be a two level array, where the first level define units, and the the second one, each command of a unit. (easily reduced to a one level array if every unit only contains one command ...)

Don't forget the teardown part then ! Or is it already included in the deploy / publish section ...

from gitness.

suggestion from @ralfschimmel that I wanted documented

Travis supports caching of directories.

In my case with maven and java I'm downloading a lot of libraries from maven central. These are stored in ~/.m2/repository and it would be nice to persist this between runs using the same image.

I was looking into docker volumes, either a mounted host directory or a shared volume between containers, but I'm not sure how to use it in relation to Drone. Would be nice if each container created by Drone is allowed to write in the shared volume to keep one up-to-date mvn repository.

Any ideas on this?

from gitness.

A problem related to this (and to matrix build) is the question of the artifacts ... If you have your (build matrix) x (your build "subunits"), that's a lot of generated stuff, and logs. How do you define which one you keep, publish, and the like ...

I believe you should keep the tool simple and stupid, and clearly limit it by design. Define some simple rules of what drone does, and most importantly does not, and stick to it. There is obviously need for a dead-simple "buildbot", travis-like CI tool, don't make the mistake of making it inaccessible, by allowing flexibility in every directions. There are other tools (frameworks) better suited for that.

The problem here, is that everyone has his own way of structuring their build, and everyone believe that their own way is the most common and obvious one.

from gitness.

I do like the idea of caching folders using volumes. Maybe something like this in the yaml

cache:
  - /home/user/bundler
  - /home/user/.m2

On the most machine, the directories would need to follow some sort of naming convention that includes the repository and branch. For example /var/cache/drone/github.com/repo/name/branch or maybe /tmp so that a reboot can flush the cache?

from gitness.

Why was this closed? Is this already implemented?
(huge bump, but i am unable to find anything about it in the new docs)

from gitness.

this was closed because caching was delegated to plugins, which give much more flexibility in terms of how and when files are cached. You can use an existing cache plugin or write your, but here is a list of existing cache plugins that people have registered: http://plugins.drone.io/tags/cache/

from gitness.