[almighty] Build Service and Build Provider Integration

[Andrew Lee Rubinger]

Welcome, Charles!

On Mon, Sep 26, 2016 at 5:45 AM, Charles Moulliard <cmoullia at redhat.com>
wrote:

> 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 ?
>

...not quite. :)  We haven't yet prescribed a DSL to define the pipeline
definition; in fact for our first release it's looking very likely that
we'll be implementing the pipeline build with Jenkins Pipeline run atop
OpenShift Online, and the definition itself would reside in Groovy
Jenkinsfiles.

So, using Almighty & its DSL language, the end user will be able to :
> - Select the systems : Github, gitlab, gerrit, hubot, jenkins, ...),
>

We launch with a subset of systems hooked together in a seamless experience
for the user through Almighty; this includes GitHub, OpenShift v3 Online,
and Jenkins.  Other service provider support is on the roadmap per an
extension and integration model, but not part of the initial MVP.


> - 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, ....)
>

Again, may be accomplished via the extension model but not MVP requirements.

>
> 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 ?
>

Doesn't look like we're quite aligned yet but we'll keep working to get
there!


> - Will the DSL, Tool be available for every IDEA Tool --> Eclipse (Che),
> IntelliJ ?
>

No DSL, but we'll be hooking the experience into WebIDE, supplied via Che.
Also there will be a "local" experience available for users to get at their
Git remotes and pull in locally.


> - Will a Web Console to manage and design the workflows be available ?
>

To add codebases, build and runtime stacks, and define runtmie environments
yes.  To alter the pipeline via a visual editor, not for MVP.

Would you like to outline your interest and intersection with this topic
here for the group? :)

S,
ALR


>
> 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
>>
>>
>


-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160926/003b83c4/attachment.htm>