[almighty] Build Service and Build Provider Integration

Tue Sep 27 07:31:25 UTC 2016

See inline

On Mon, Sep 26, 2016 at 6:10 PM, Andrew Lee Rubinger <alr at redhat.com> wrote:

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

>> Do you mean that you will support what OpenShift has developed (include
PipelineStrategy within OpenShift Template BuildConfig) and which is
described here -
https://docs.openshift.org/latest/architecture/core_concepts/builds_and_image_streams.html#pipeline-build
 ?
If this is the case, this vision is a bit different from what I propose
here: https://redhat-microservices.github.io/docs/#_introduction_2 where a
commit pushed in a Git Repo will trigger the pipeline job of Jenkins as a
webhook has been configured within Gogs/Gitlab .... Can we align our
positions ?

> with Jenkins Pipeline run atop OpenShift Online
>

>> Do you only target OpenShift online ? What about companies using
OpenShift within their premises ?

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

>> What is 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? :)
>

>> For sure

>
> 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/20160927/679004a1/attachment.htm>