[almighty] Build Service and Build Provider Integration

[Charles Moulliard]

Hi,

If I understand correctly, what you propose to do with the Almighty project
is to create an Api, Tool & DSL to allow an end user to by example design a
CI/CD workflow ?

So, using Almighty & its DSL language, the end user will be able to :
- Select the systems : Github, gitlab, gerrit, hubot, jenkins, ...),
- Describe the actions to be performed as a collection of Routes that we
could design as such : from git-commit in github -> triggered
job-mycool-job in Jenkins -> Notify to Letschat with Hubot and
Approve/Reject, ....)

Remark : Discussions with Openshift will be required to validate the list
of the applications they could support; Jenkins, Hubot, Gitlab, Gogs, ...

- Is my assumption correct ?
- Will the DSL, Tool be available for every IDEA Tool --> Eclipse (Che),
IntelliJ ?
- Will a Web Console to manage and design the workflows be available ?

Regards,

Charles

On Fri, Sep 23, 2016 at 8:28 PM, Andrew Lee Rubinger <alr at redhat.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160926/d8bf4ab9/attachment.htm>