polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <paulmer...@apache.org>
Subject Re: yeoman-work back to develop
Date Sat, 03 Jun 2017 12:24:26 GMT

I took a quick look at the project generator integration tests.

First thing, I just tried on a computer where I don't have docker
installed and the tests present in generated projects simply fail with a
not so obvious error.

We should not require docker for a successful build of generated
projects. This would mean that the tests should be skiped/ignored if a
docker service is not available.

We should also not use `latest` tags for docker images otherwise we
can't guarantee that the generated projects will work in the future.
About Memcached, I noticed that the docker image used is
`memcached:latest`. The extension tests (as opposed to tests of
generated projects) use the Alpine Linux variant instead, see
maybe there's something different here.

Lastly, the docker rule for MongoDBEntityStore is missing. Note that the
extension tests use an embedded version of MongoDB.

I've been quite busy this week. I'll have some time early next week to
try to fix stuff and roll a second release candidate for 3.0 if we are

Given that the tests take quite a long time to run it's unpleasant to
not be able to easily run a single permutation while working on the
underlying plumbing. Even the reduced set of tests run by
:tools:generator:npmTest takes several minutes. Plus I miss proper test
reports with output and involved paths. Moreover, these tests are
unfortunately currently disabled on CI. We can look at these problems
post 3.0.



Niclas Hedhman a écrit :
> Gang,
> I just merged back all the work that has been done on yeoman-work branch.
> I think the build is Ok, the "checkDist" worked ok locally, think I tried
> with clean local setup.
> Well, if it doesn't I will deal with it tomorrow, unless someone beats me
> to it.
> The main thing outstanding is that generated testcase is marked @Ignore,
> until I can figure out all the remaining Docker starts needed. For
> instance, Memchched is used for most tests, and if I start an memcached
> server locally, many of the tests works, but with the Docker start that I
> am attempting, something is not right.
> Other thing that was fixed was the Configuration bootstrapping, now using
> the Module of the ConfigurationComposite for any Deserializer service
> needed.
> The stacktrace addition is there as well.
> And probably more that I have forgotten about. For instance, some name
> changes to try to stay unified and simplified code generation.
> All-in-all, I think the code generation facility is a good step towards a
> really great way to get started, without the initial struggles that we all
> face in the beginning to get structure working.
> Cheers

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message