kpack monitors rfc #433
kpack monitors rfc #433
Conversation
Codecov Report
@@ Coverage Diff @@
## master #433 +/- ##
=======================================
Coverage 67.33% 67.33%
=======================================
Files 85 85
Lines 3612 3612
=======================================
Hits 2432 2432
Misses 894 894
Partials 286 286 Continue to review full report at Codecov.
|
|
@matthewmcnew I think this will alleviate some complexity for folks and drive adoption. I would push back on one assumption that polling is the best default strategy. A polling strategy usually requires long-lived credentials. Our usage at Spaceship only provides kpack with short-lived credentials. With our usage any extensible polling resources create builds that fail in the prepare phase with invalid credentials. This may be a case of we need to get off our butts and move to a Github App Source Resolver, but the separation of concerns works pretty well for us right now and limits the attack vectors on the build service. I think the concept of Build Triggers could be more extensible and defers pushing/polling to an implementation detail of the external service sending Build Events. kpack could allow external services to register Build Triggers, provide a signature key for request signing, expose a service, and define the data format for the Build Events. Then any number of external services could monitor published build images, run images, maven repos, CVE lists, or other data. This implementation would also allow maintainers of those build images, run images, and libraries to push Build Events to kpack when images/libraries/patches/etc are published. I would be interested in hearing more about the maven repo use case in particular. Is that documented anywhere? |
|
A bit of additional user validation for this feature. A firmly entrenched CF operations team at McKesson that is playing around with kpack recently enquired about a "hands off" configuration of kpack. Given they deeply understand buildpacks and stemcells, these users feel comfortable turning over build automation to kpack whenever upstream dependencies change rather than managing this process manually. I think this feedback is interesting because we are not sure if this feature would be useful to large companies given that many frequently desire manual centralized management of new dependency versions. |
| - Decouple kpack critical core functionality from possibly unstable i/o intensive polling resources. | ||
|
|
||
| ### Actions to take: | ||
| Start a new project/repo called kpack-monitors which will provide a set of custom resources that monitor external systems for relevant updates to kpack resources. |
There was a problem hiding this comment.
Is there a reason why this would need to be a seperate project/repo? It seems to me like this functionality would be pretty much inline with this project and even more so is already a part of it. What value is the overhead of managing two repos providing?
| _MonitorMavenSource_: A resource that will monitor a maven repo for new versions of a published jar artifact. | ||
|
|
||
| *Possible Candidates*: | ||
| _MonitorGitSource_: A resource that monitors a git repo for updated revisions. |
There was a problem hiding this comment.
Why is this a "possible" candidate as opposed to something like MonitorMavenSource?
Readable