Re: split of mockup / plone.mockup
Timo Stollenwerk <tisto-z4DKO/[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.devel |
|---|---|
| Message-ID | <[email protected]> |
Am 09.03.15 um 19:08 schrieb Timo Stollenwerk: > Hi Johannes, > > making mockup installable via bower is a worthwile goal. Thanks for > working on that! > > Though, I see a problem with using git submodules. It is already quite > hard to create a proper CI setup on top of mr.developer, and using git > submodules will make this even harder. Here is why: > > We are basically nesting our development packages into our main > repository with mr.developer. This makes it hard to impossible to > trigger one Jenkins job per commit (we tried very smart stuff with > mr.roboto and we failed miserably, you have to store every single hash > value and every version pinning for each pkg and re-run buildout with > this). We are still aiming for 1 commit = 1 build. Though, adding a > second nested level (git submodules) within our already nested setup > will make this impossible. We might be able to somehow pin our modules > if we do releases in the future. We are not going to be able to do this > in a structure that is nested twice. > > Futhermore, my personal experience with git submodules is that even when > working with in manually, it is nothing but unpredictable pain. > > In addition to the uncertainty that buildout and mr.developer already > put into our CI setup, you just introduced another one. > > I think we should try to find another way to solve this problem. I'm not > sure if we still take "mockup should be used outside Plone" seriously. > Though, in any case I think we should test and release mockup > separately. What if the mockup CI system (travis?) creates a new release > if all unit tests pass. The Plone CI could pick up the latest release > and we would just have to make sure the travis job triggers the Jenkins > CI. Plone would just install the latest mockup development version via > bower. Sorry, I mixed things up with the CI pipeline for my current project. :) We do not want to run npm/bower on our Jenkins job. Therefore we would need a Python egg for each mockup commit that can be picked up by the Jenkins job instead of a bower release. I guess we could set up a private pypi for that if necessary. Cheers, Timo ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/