[almighty] Build Service and Build Provider Integration

[Andrew Lee Rubinger]

Hi, all:

Let's start to work through the integration of a Build Service with
Almighty.  I'll lay out a foundation here, but encourage everyone to poke
holes in the design until we hit a stable base.

The common user story which spans several experiences in the PDD looks a
bit like this:

  As a user, I can trigger my codebases (repos/modules) in an Almighty
project to enter a configurable build process so that sources may be
reliably transformed into actionable artifacts.

Further requirements for the above user story:
* The user can view the state of the executing build
* The user can view or access all resulting artifacts of the build (ie.
reports, logs, deployables)
* The user can access underlying authoritative systems carrying out the
build

We've also seeded some very primitive ideas how that translates into a
featureset for domain types and actions, pending this PR on
almighty/devdocs:

  https://github.com/almighty/almighty-devdoc/pull/75

Let's use that document as a central design guideline as we work through
this.

>From an architectural standpoint, I imagine this might be laid out in the
following fashion:

Build Service - Contains the Almighty view of domain objects and actions;
exposed out through the Almighty public API
Build UI Extension - Communicates with the Build Service via the Almighty
public API.  We'll want to bring in components already made elsewhere (ie.
pieces used in the OpenShift Console).
Build SPI - Defined by Almighty using Build Service domain types, contains
the contract providers must implement to be an external service fulfilling
the needs of a Build System
OpenShift Build Provider - Implementation of the Build SPI which fulfills
the contract using the OpenShift Build API.
Jenkins Build Provider - Same as above, fulfilling the contract using
Jenkins API directly. (stretch, but showcases how we can make N providers
for the system)

As you can see, folks will have a part to play at nearly every layer of the
system: core/backbone, Build/Pipeline, UI, UXD, etc.

Goals for next week: evolve our understanding of the desired architectural
model[1] to fit the Build use case.  Continue working to establish how
Services and SPIs are registered in Almighty and put the core features for
extensibility in place.

I've slated a public development discussion on Freenode #almighty, Thursday
29th at 9:00am EDT to walk through the core architecture that would support
integrations like the Build one outlined here.

Until then, thoughts in this thread and PRs on the devdocs welcome!

S,
ALR

[1] https://drive.google.com/open?id=0B10zSvDl_cuwMHZtTmR1RVIteGM, with
apologies to non-RHT that I don't have a mechanism to make these charts
public yet.  Screencap is attached.

-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160923/0a4aa8c6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot1.png
Type: image/png
Size: 79383 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160923/0a4aa8c6/attachment.png>