Hi,
I've changed the jobs
* http://ci.hibernate.org/job/hibernate-ogm-master/
* http://ci.hibernate.org/view/Pull%20Requests/job/hibernate-ogm-PR/
into multi-config jobs which run the MongoDB tests once embedded and once
against the external instance. The former has an additional configuration
a
+1
On Wed, Jul 10, 2013 at 11:15 AM, Sanne Grinovero wrote:
> On 10 July 2013 10:12, Hardy Ferentschik wrote:
> >
> > On 10 Jan 2013, at 11:06 AM, Gunnar Morling
> wrote:
> >
> >> I think the proper way of doing this kind of thing in Jenkins would be
> to
> >> set up a "multi-configuration" j
On 10 July 2013 10:12, Hardy Ferentschik wrote:
>
> On 10 Jan 2013, at 11:06 AM, Gunnar Morling wrote:
>
>> I think the proper way of doing this kind of thing in Jenkins would be to
>> set up a "multi-configuration" job which builds one project applying
>> different configurations (here once with
On 10 Jan 2013, at 11:06 AM, Gunnar Morling wrote:
> I think the proper way of doing this kind of thing in Jenkins would be to
> set up a "multi-configuration" job which builds one project applying
> different configurations (here once with embedded and once with external
> MongoDB). This gives
Hi,
In a copy of the OGM job I've added a post build step which runs
"hibernate-ogm-mongodb" and "hibernate-ogm-integrationtest-mongodb" against
an external MongoDB.
This works as expected, the only shortcoming being, that the test results
reported by Jenkins are always those created by the embed
+1
We need to test it, not just for the functional aspect of our code but
to make sure the _build_ works fine in both configurations.
Also, I'm pretty sure the server mode and embedded mode can not
guarantee to be using the same MongoDB version so it's possible that a
fix made by someone is verifi
2013/7/9 Emmanuel Bernard
> Custom configuration is not something you would exercise for example.
> I'm talking about hostname, ports, the ability to forbid plain "table"
> scan.
>
> Gunnar's proposal for an additional slave job only running the mongodb
> module with the non embedded mode seems t
Custom configuration is not something you would exercise for example.
I'm talking about hostname, ports, the ability to forbid plain "table"
scan.
Gunnar's proposal for an additional slave job only running the mongodb
module with the non embedded mode seems the easiest solution.
Emmanuel
On Tue
I just don't get the point. AFAIU the embedded version is nothing else than a
downloaded mongodb,
installed in a given directory and started by the plugin. Where is the
difference to a "proper"
mongodb instance? Installing MongoDB is nothing else than getting the
distribution and running the
dae
2013/7/8 Sanne Grinovero
> On 8 July 2013 11:08, Gunnar Morling wrote:
> > 2013/7/8 Sanne Grinovero
> >>
> >> Nice!
> >> now a tricky question: how can I get the tests to run both with
> >> embedded and external on CI?
> >>
> >> I guess I need two jobs :-(
> >
> >
> > Yes, as of know, you'd nee
On 8 July 2013 11:08, Gunnar Morling wrote:
> 2013/7/8 Sanne Grinovero
>>
>> Nice!
>> now a tricky question: how can I get the tests to run both with
>> embedded and external on CI?
>>
>> I guess I need two jobs :-(
>
>
> Yes, as of know, you'd need two jobs. If really needed, one could probably
2013/7/8 Sanne Grinovero
> Nice!
> now a tricky question: how can I get the tests to run both with
> embedded and external on CI?
>
> I guess I need two jobs :-(
>
Yes, as of know, you'd need two jobs. If really needed, one could probably
make it run against both by configuring several surefire
Nice!
now a tricky question: how can I get the tests to run both with
embedded and external on CI?
I guess I need two jobs :-(
On 8 July 2013 11:01, Gunnar Morling wrote:
> Hi,
>
> I've submitted PR #197 [1] for OGM-295.
>
> This makes the "mongodb" module part of the OGM build by default, execu
Hi,
I've submitted PR #197 [1] for OGM-295.
This makes the "mongodb" module part of the OGM build by default, executing
the tests on an "embedded" MongoDB instance. "Embedded" means in this
context, that the original distribution *.tar.gz is retrieved from
mongodb.org, unpacked and an external mo
Thanks!
On 4 July 2013 11:26, Gunnar Morling wrote:
> Thanks, Sanne, for creating the issue. I can do that, already assigned it to
> me.
>
> --Gunnar
>
>
>
> 2013/7/4 Sanne Grinovero
>>
>> Created as
>> https://hibernate.atlassian.net/browse/OGM-295
>>
>> volunteers?
>>
>>
>> On 28 June 2013 10:
Thanks, Sanne, for creating the issue. I can do that, already assigned it
to me.
--Gunnar
2013/7/4 Sanne Grinovero
> Created as
> https://hibernate.atlassian.net/browse/OGM-295
>
> volunteers?
>
>
> On 28 June 2013 10:20, Hardy Ferentschik wrote:
> >
> > On 28 Jan 2013, at 11:15 AM, Emmanuel
Created as
https://hibernate.atlassian.net/browse/OGM-295
volunteers?
On 28 June 2013 10:20, Hardy Ferentschik wrote:
>
> On 28 Jan 2013, at 11:15 AM, Emmanuel Bernard wrote:
>
>> I wonder how you can debug things though and look at the content outside
>> your tests? I guess you would install
On 28 Jan 2013, at 11:15 AM, Emmanuel Bernard wrote:
> I wonder how you can debug things though and look at the content outside
> your tests? I guess you would install a regular mongodb on a different
> port.
Right, for active development and/or debugging it makes probably sense to have
a regu
This looks like a good idea and fixes the workaround we had around
optional testing based on profiles.
The only drawback is that we still need to make sure OGM is naturally
usable without it but if we use
https://github.com/joelittlejohn/embedmongo-maven-plugin
it looks like the mongodb instance i
2013/6/27 Sanne Grinovero
> I heard good praises about this project, so it might be good, but I'd
> be concerned that we're not testing the real thing.
>
> This could be great to mock the db for some operations, but could it
> replace all of them while providing us with the same level of
> confid
On 27 Jan 2013, at 3:23 PM, Sanne Grinovero wrote:
> I heard good praises about this project, so it might be good, but I'd
> be concerned that we're not testing the real thing.
I thought it is running the real thing. It is not mocking mongo, it is just a
wrapper to
download/install/start/stop
I heard good praises about this project, so it might be good, but I'd
be concerned that we're not testing the real thing.
This could be great to mock the db for some operations, but could it
replace all of them while providing us with the same level of
confidence ?
What will the gap be in release
On 27 Jan 2013, at 2:20 PM, Gunnar Morling wrote:
> I just came across across "EmbedMongo" [1] which provides a way to run
> MongoDB embedded within an application. This is e.g. convenient for tests
> as it doesn't require a separately installed MongoDB instance.
Interesting. I think that could
Hi all,
I just came across across "EmbedMongo" [1] which provides a way to run
MongoDB embedded within an application. This is e.g. convenient for tests
as it doesn't require a separately installed MongoDB instance.
I've tried it out with a single test and it worked as expected.
Unfortunately Mon
24 matches
Mail list logo
