<div dir="ltr">See inline<div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="color:rgb(74,74,74);font-weight:bold;font-family:"liberation sans","open sans",sans-serif;line-height:22.4px"><span></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Sep 26, 2016 at 6:10 PM, Andrew Lee Rubinger <span dir="ltr"><<a href="mailto:alr@redhat.com" target="_blank">alr@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Welcome, Charles!<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Mon, Sep 26, 2016 at 5:45 AM, Charles Moulliard <span dir="ltr"><<a href="mailto:cmoullia@redhat.com" target="_blank">cmoullia@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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 ?</div></div></blockquote><div><br></div></span><div>...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 </div></div></div></div></blockquote><div><br></div><div>>> Do you mean that you will support what OpenShift has developed (include PipelineStrategy within OpenShift Template BuildConfig) and which is described here - <a href="https://docs.openshift.org/latest/architecture/core_concepts/builds_and_image_streams.html#pipeline-build">https://docs.openshift.org/latest/architecture/core_concepts/builds_and_image_streams.html#pipeline-build</a> ?</div><div>If this is the case, this vision is a bit different from what I propose here: <a href="https://redhat-microservices.github.io/docs/#_introduction_2">https://redhat-microservices.github.io/docs/#_introduction_2</a> 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 ?</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>with Jenkins Pipeline run atop OpenShift Online</div></div></div></div></blockquote><div><br></div><div>>> Do you only target OpenShift online ? What about companies using OpenShift within their premises ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>, and the definition itself would reside in Groovy Jenkinsfiles.</div><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>So, using Almighty & its DSL language, the end user will be able to :</div><div>- Select the systems : Github, gitlab, gerrit, hubot, jenkins, ...), </div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>>> What is MVP ? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- 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, ....)</div></div></blockquote><div><br></div></span><div>Again, may be accomplished via the extension model but not MVP requirements.</div><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Remark : Discussions with Openshift will be required to validate the list of the applications they could support; Jenkins, Hubot, Gitlab, Gogs, ...</div><div><br></div><div>- Is my assumption correct ?</div></div></blockquote><div><br></div></span><div>Doesn't look like we're quite aligned yet but we'll keep working to get there!</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Will the DSL, Tool be available for every IDEA Tool --> Eclipse (Che), IntelliJ ?</div></div></blockquote><div><br></div></span><div>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.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Will a Web Console to manage and design the workflows be available ? </div></div></blockquote><div><br></div></span><div>To add codebases, build and runtime stacks, and define runtmie environments yes. To alter the pipeline via a visual editor, not for MVP.</div><div><br></div><div>Would you like to outline your interest and intersection with this topic here for the group? :)</div></div></div></div></blockquote><div><br></div><div>>> For sure </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>S,</div><div>ALR</div><div><div class="gmail-h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards,</div><div><br></div><div>Charles</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><div><div>On Fri, Sep 23, 2016 at 8:28 PM, Andrew Lee Rubinger <span dir="ltr"><<a href="mailto:alr@redhat.com" target="_blank">alr@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><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" target="_blank">https://github.com/almighty/<wbr>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" target="_blank">https://drive.google.com/o<wbr>pen?id=0B10zSvDl_cuwMHZtTmR1RV<wbr>IteGM</a>, with apologies to non-RHT that I don't have a mechanism to make these charts public yet. Screencap is attached.</div><span><font color="#888888"><div><div><br></div>-- <br><div><div dir="ltr">Red Hat Developer Programs Architecture<div>@ALRubinger</div></div></div>
</div></font></span></div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
<br></span></blockquote></div><br></div></div>
</blockquote></div></div></div><div><div class="gmail-h5"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Red Hat Developer Programs Architecture<div>@ALRubinger</div></div></div>
</div></div></div></div>
</blockquote></div><br></div></div>