Bug 1250885 - RFE: Build triggers for non-Docker / non-web-hook sources
RFE: Build triggers for non-Docker / non-web-hook sources
Status: CLOSED WONTFIX
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE (Show other bugs)
3.0.0
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Mike Barrett
Johnny Liu
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-06 04:43 EDT by Chmouel Boudjnah
Modified: 2016-04-14 08:53 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-14 08:53:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chmouel Boudjnah 2015-08-06 04:43:14 EDT
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.
Comment 2 Ben Parees 2016-01-07 22:30:36 EST
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.

Note You need to log in before you can comment on or make changes to this bug.