<div dir="ltr">Hi, all:<div><br></div><div><div>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. </div><div><br></div><div>The common user story which spans several experiences in the PDD looks a bit like this:</div><div><br></div><div>  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.</div><div><br></div><div>Further requirements for the above user story:</div><div>* The user can view the state of the executing build</div><div>* The user can view or access all resulting artifacts of the build (ie. reports, logs, deployables)</div><div>* The user can access underlying authoritative systems carrying out the build</div><div><br></div><div><div>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:</div><div><br></div><div>  <a href="https://github.com/almighty/almighty-devdoc/pull/75">https://github.com/almighty/almighty-devdoc/pull/75</a></div></div><div><br></div><div>Let's use that document as a central design guideline as we work through this.</div><div><br></div><div>From an architectural standpoint, I imagine this might be laid out in the following fashion:</div><div><br></div><div>Build Service - Contains the Almighty view of domain objects and actions; exposed out through the Almighty public API</div><div>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).</div><div>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</div><div>OpenShift Build Provider - Implementation of the Build SPI which fulfills the contract using the OpenShift Build API.  </div><div>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)</div><div><br></div><div>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.  </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>Until then, thoughts in this thread and PRs on the devdocs welcome!</div><div><br></div><div>S,</div><div>ALR</div><div><br></div><div>[1] <a href="https://drive.google.com/open?id=0B10zSvDl_cuwMHZtTmR1RVIteGM">https://drive.google.com/open?id=0B10zSvDl_cuwMHZtTmR1RVIteGM</a>, with apologies to non-RHT that I don't have a mechanism to make these charts public yet.  Screencap is attached.</div><div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Red Hat Developer Programs Architecture<div>@ALRubinger</div></div></div>
</div></div></div>