[almighty] Build Service and Build Provider Integration

[Tomas Nozicka]

Hi Andy,

thanks for starting the discussion.

There is one area I am not clear about: You talk here only about
"Build" part and getting artifacts back, but I don't see any mentions
of CI or CD parts which were crucial for our pipelines in Catapult.

Would you mind to elaborate on what the plan for ALM is? Specifically
with respect to "ALM Build service".

Maybe you see it all as part of what "Build" means and I don't, but I
didn't find any particular user stories in [1] about CI/CD either.

Thanks,
Tomas

[1] - https://github.com/almighty/almighty-devdoc/blob/master/design/bu
ild_service.adoc#user-stories


On Pá, 2016-09-23 at 14:28 -0400, Andrew Lee Rubinger wrote:
> 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
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public