Speaking of tests: we have unit tests and we will have integration tests. Unit tests may not require a fully deployment application, but integration tests do. The nature of tests executed during the CI/gate process will determine what Solum API needs to be invoked [based on if we we need a fully deployment environment to run the integration tests or need something less elaborate to run the unit tests] ________________________________________ From: Clayton Coleman [ccole...@redhat.com] Sent: Wednesday, November 13, 2013 3:09 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Gated Source Code Flow (was: Weekly Team Meeting)
----- Original Message ----- > Clayton, > > On Nov 13, 2013, at 11:41 AM, Clayton Coleman <ccole...@redhat.com> > wrote: > > > ----- Original Message ----- > >> Hello, > >> > >> Solum meets Tuesdays at 1600 UTC in #openstack-meeting-alt (formerly in > >> #solum) > >> > >> > >> Note: Due to the Nov 3rd change in Daylight Savings Time, this now happens > >> at > >> 08:00 US/Pacific (starts in about 45 minutes from now) > >> > >> > >> Agenda: https://wiki.openstack.org/wiki/Meetings/Solum > > > > In the meeting yesterday there was a mention of a "gated" source code flow > > (where a push might go to an external system, and the gate system > > github/gerritt/etc would control when the commit goes back to the primary > > repository). I've added that flow to > > https://wiki.openstack.org/wiki/File:Solum_r01_flow.jpeg as well as a > > mention of the DNS abstraction (a deployed assembly may or may not have an > > assigned DNS identity). > > Are the two "source change notification abstraction" flows really different? > Could we express this with two lines converging on "Notify Solum API …" in a > single flow with two similar entrances. I think you hit on something fundamental - I reswizzled the diagram to show the "gate" flow moving into the normal "source push" flow after tests pass. https://wiki.openstack.org/w/images/7/72/Solum_r01_flow.jpeg > > One key difference that I noticed between those two proposed flows are that > the "gate" type uses the Solum API to test code, and the "push" one does > not. Perhaps both should run unit tests in the same way with an option to > bypass steps for those who don't want them? Yeah - this also highlights that an input to the "build" flow might be the desired outcome - possibly "no deploy", "deploy", "deploy as temporary assembly X", or "deploy as temporary assembly X without tests". There may be consumers who wish to make Solum the end result of a flow, but if the tools and abstractions Solum offers for build and deploy are compelling, we should expect to want to let external systems utilize Solum as much as possible. Another point of discussion is whether "test" is part of both "build" and "deploy", or just part of "deploy". If it's part of both, perhaps "deploy" and "build" need to have similar ways of letting someone run their tests at the right opportunities. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
