[pytest-dev] Testing pytest releases using devpi and CI servers

[Holger Krekel]

Haven't played yet with your integration code. So I can't contrast it.  It was indeed a more general comment regarding what I perceive as the missing piece in open source  testing infrastructure.  

It's true that I kind of am uncomfortable with using commercial hosting services like appveyor and Travis if the platform is not driven by open source software. Practicality beats purity sometimes though. 

Cheers holger 

On January 16, 2016 1:37:42 PM PST, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>Hi Holger,
>
>On Sat, Jan 16, 2016 at 6:01 PM Holger Krekel <holger at merlinux.eu>
>wrote:
>
>> The crucial part that is missing wrt to devpi/tox/pytest is the
>ability to
>> automatically schedule tests to hosts. Rackspace provides us some
>funding
>> for open source which we can use to have a Windows and a Linux host
>for
>> running tests. A Windows machine already exists, 4 cores, 8 gigs ram.
>We
>> could make them ssh accessible for all ssh keys we have from
>contributors
>> for the time being so that no one needs to setup hosts and everyone
>can go
>> to the machines to check failures out, reproduce them, work on them.
>If
>> someone has a nice ansible/chef/... Recipe for setting up a Linux box
>with
>> all interpreters, headers files and c compiler environment,
>virtualenv
>> that'd be helpful. I can also hand someone credentials to start/stop
>> machines. Help welcome.
>>
>> Maybe a little script that goes to the hosts and runs "devpi test..."
>> would be good to automate the final step
>>
>
>Do you mean regarding devpi in general, or for testing pytest releases
>specifically?
>
>If the latter, what would be the advantages of using such a system
>instead
>of the existing Travis/AppVeyor infrastructure? With my quick
>experiment I
>was able to successfully test 2.8.5 using devpi across all interpreter
>versions in Linux and Windows, integrated with GitHub. It would be just
>a
>couple more hours of work to make the repository generic and useful by
>all
>pytest contributors in order to test the package before a release.
>
>
>> The other remaining automation issues are the docs/pdf generation and
>> pytest.org docs push.
>>
>
>Sure. I also think this can be handled by Travis, we just would need to
>generate a new deployment key for Travis, which we could securely
>encrypt
>into the .travis.yml file itself. This way documentation could be
>automatically generated and uploaded. I think Ronny has a similar idea.
>
>Cheers,
>Bruno.
>
>
>>
>> Greetings from sf, holger
>>
>>
>>
>>
>>
>>
>>
>> On January 14, 2016 9:15:37 PM PST, Florian Bruhin
><me at the-compiler.org>
>> wrote:
>>>
>>> Hey,
>>>
>>> * Bruno Oliveira <nicoddemus at gmail.com> [2016-01-15 00:15:39 +0000]:
>>>
>>>>  I created a small repository[1] which only contains appveyor and
>travis
>>>>  scripts which simply use "devpi test" to test and publish results
>for the
>>>>  pytest 2.8.5 release[2] in Travis and AppVeyor.
>>>>
>>>
>>> Thanks! This is about what I imagined when talking about it in the
>>> Hangout. I wanted to write a more detailed proposal to the ML but
>>> never got to it ;)
>>>
>>> As I said there, the devpi part was the most painful point of doing
>>> the release for me (not because of devpi directly, I think). I had
>to
>>> set it up on multiple machines, and had various trouble ([1]) which
>>> nobody else seems to be having, which why I'd like a reproducible
>>> environment.
>>>
>>> [1] https://github.com/pytest-dev/pytest/issues/1114
>>>     https://github.com/pytest-dev/pytest/issues/1115
>>>     https://github.com/pytest-dev/pytest/issues/1116
>>>
>>> Florian
>>>
>>>
>> --
>> Sent using mobile touch keys, increased chances for errors and
>> misunderstandings. Enjoy!
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>

-- 
Sent using mobile touch keys, increased chances for errors and misunderstandings. Enjoy! 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20160116/6670a988/attachment-0001.html>