<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><br></div><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>- 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><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>- Will the DSL, Tool be available for every IDEA Tool --> Eclipse (Che), IntelliJ ?</div><div>- Will a Web Console to manage and design the workflows be available ? </div><div><br></div><div>Regards,</div><div><br></div><div>Charles</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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/<wbr>open?id=0B10zSvDl_<wbr>cuwMHZtTmR1RVIteGM</a>, with apologies to non-RHT that I don't have a mechanism to make these charts public yet. Screencap is attached.</div><span class="HOEnZb"><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>______________________________<wbr>_________________<br> almighty-public mailing list<br> <a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br> <a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br> <br></blockquote></div><br></div></div>