Description of problem: We have this requirement coming up from a client deploying OpenShift and would like to know if this is something we can have added to the OpenShift backlog. Let us know if that's something we could : As a platform and application provider, I would like a new Docker image build to occur when dependent runtime components become available. As described here, currently only web hooks or internal Docker registry updates can trigger builds. This is even more important then one might assume, because - most for most open source components we can't trigger build via webhooks - nor can we rely on some Docker images (and even less so in the internal registry), because we have to re-build public Docker images based on OpenShift base images. A minimal strategy that should be supported is: - Store what external dependency has already been downloaded, e.g. http://some.mirror/zookeeper-3.3.6/zookeeper-3.3.6.tar.gz - Check whether a new URL becomes available, if so, download, e.g. - Store what external dependency has already been downloaded, e.g. http://some.mirror/zookeeper-3.3.7/zookeeper-3.3.7.tar.gz -- Some logic to look ahead (e.g. for 3.3.8) if 3.3.7 is never released or pulled back -- configurable strategy on which level major/minor/maint the build should be triggered -- potentially some config for check-sum URL -- optionally, zip instead of tar.gz should be supported.
This is a very open-ended problem to solve (supporting the vast variety of external dependencies, versioning schemes, and doing polling against them). This seems like a problem that would be better solved by a custom implementation of a poller against the appropriate resource, coupled with a generic webhook trigger to run a build when the resource changes. It does not seem likely we'd tackle this feature in the near term.