<div dir="ltr">Welcome, Charles!<br><div class="gmail_extra"><br><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;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><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 with Jenkins Pipeline run atop OpenShift Online, and the definition itself would reside in Groovy Jenkinsfiles.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><div>Again, may be accomplished via the extension model but not MVP requirements.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><div>Doesn't look like we're quite aligned yet but we'll keep working to get there!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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><br></div><div>S,</div><div>ALR</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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 class="h5">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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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 class="">______________________________<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><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Red Hat Developer Programs Architecture<div>@ALRubinger</div></div></div> </div></div>