You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary Martin <ga...@wandisco.com> on 2012/08/02 03:31:43 UTC
CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound 0.1.0
(incubating) (RC1))
On 02/08/12 01:57, Olemis Lang wrote:
> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>> Just for the record, I have downloaded reviewed the files to my technical
>>> ability.
>>>
>>> +1 for the release from me.
>>>
> I second that . The only thing I can mention is that even if manual
> installation procedure works for me , on the other hand all the
> attempts I made so as to install it from tarball in a Jenkins build
> job have failed . This is mainly because :
>
> 1. I'm not a proficient Jenkins user ...
> 2. it seems there's an issue with virtualenv somewhere and ...
> 3. I've not been able to dedicate any time to this task after the
> few initial experiments
I appear to have been able to get things going with Buildbot with the
virtualenv instructions, although I am not convinced that you can really
activate the virtualenv in a buildstep. I didn't try this and instead
resorted to a bit of trickery through which python binary was used after
virtualenv creation.
To be fair, there is no specific need to use virtualenv, as long as you
have a fresh environment each time. My attempts so far have not been
with throwaway VMs. Of course, I am sure that there will be other ways
to isolate a python environment.
Cheers,
Gary
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
oops !
.. [1] Jenkins » bh-trac-test » #45 » Console Output
(http://hudson.testrun.org/job/bh-trac-test/45/console)
On 8/5/12, Olemis Lang <ol...@gmail.com> wrote:
> On 8/5/12, Olemis Lang <ol...@gmail.com> wrote:
>> On 8/5/12, Gary Martin <ga...@wandisco.com> wrote:
>>
> [...]
>>
>>> If you
>>> don't have an appropriate path for a local repository it probably is not
>>> worth specifying either option.
>>>
>>
>> I c ... I'll try again and let you know .
>
> bingo !
> works ok without repos options [1]_
> thnx !
> ;)
>
>> Nonetheless , afaics , that
>> should work due to the fact that those values are the ones used in
>> trac-admin initenv interactive console as well as trac.ini to specify
>> «no repository» .
>>
>
> I think maybe there's a chance to get this done for Release 2 ... ?
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
On 08/06/2012 03:50 AM, Olemis Lang wrote:
>> Nonetheless , afaics , that
>> should work due to the fact that those values are the ones used in
>> trac-admin initenv interactive console as well as trac.ini to specify
>> «no repository» .
>>
> I think maybe there's a chance to get this done for Release 2 ... ?
>
Well, as far as I can tell, no, this is not valid input to the
trac-admin initenv command and it requires both positional arguments.
As a bug, it may well get fixed for the next release. I'll probably just
make it silently drop any repo type specification when there is no path
specified.
For the other symmetric failure (no repo type specified but a path
provided), there may be a potential to detect what the repository type
is but for the moment I think I will choose failure with an informative
message.
Cheers,
Gary
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
On 8/5/12, Olemis Lang <ol...@gmail.com> wrote:
> On 8/5/12, Gary Martin <ga...@wandisco.com> wrote:
>
[...]
>
>> If you
>> don't have an appropriate path for a local repository it probably is not
>> worth specifying either option.
>>
>
> I c ... I'll try again and let you know .
bingo !
works ok without repos options [1]_
thnx !
;)
> Nonetheless , afaics , that
> should work due to the fact that those values are the ones used in
> trac-admin initenv interactive console as well as trac.ini to specify
> «no repository» .
>
I think maybe there's a chance to get this done for Release 2 ... ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
On 8/5/12, Gary Martin <ga...@wandisco.com> wrote:
> Hi Olemis,
>
:)
> Remember that my alteration to your patch meant that the positional
> arguments for an initenv remain unchanged so that should not be the issue.
>
you are right . I forgot
:-/
> I think I have spotted the most likely reason for the error you see.
> Although it is not clear what arguments you are passing to the
> bloodhound_setup.py,
it's something like this
{{{
#!python
call([python, 'bloodhound_setup.py',
'-d', 'sqlite',
'--admin-password=testrun', '--admin-user=bhadmin',
'--repository-type=svn', '--repository-path='],
cwd=folder_installer, env=ENVIRONMENT)
}}}
> I think you might be specifying either the
> repository type or repository path.
yes
> I see that the logic around that is
> a little suspect in that there is no check to see if only one of these
> is provided.
>
I'm supplying both but repository path is empty. That usually means
«no repository»
> I will add a check for that at some point but could you check if you
> pass either the --repository-type or --repository-path options.
yes , both
> If you
> don't have an appropriate path for a local repository it probably is not
> worth specifying either option.
>
I c ... I'll try again and let you know . Nonetheless , afaics , that
should work due to the fact that those values are the ones used in
trac-admin initenv interactive console as well as trac.ini to specify
«no repository» .
[...]
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
Hi Olemis,
Remember that my alteration to your patch meant that the positional
arguments for an initenv remain unchanged so that should not be the issue.
I think I have spotted the most likely reason for the error you see.
Although it is not clear what arguments you are passing to the
bloodhound_setup.py, I think you might be specifying either the
repository type or repository path. I see that the logic around that is
a little suspect in that there is no check to see if only one of these
is provided.
I will add a check for that at some point but could you check if you
pass either the --repository-type or --repository-path options. If you
don't have an appropriate path for a local repository it probably is not
worth specifying either option.
Cheers,
Gary
On 05/08/12 06:11, Olemis Lang wrote:
> u r a genius !
> That works for me too . Now all dependencies are installed
> :)
>
> Nonetheless , I noticed something is happening in there [1]_ . AFAICS
> an error is raised when Trac environment is created and installer
> configuration saved . Details follow
>
> {{{
> Successfully installed Babel BloodhoundDashboardPlugin
> BloodhoundMultiProduct BloodhoundTheme Genshi Pygments pytz Trac
> TracAccountManager TracPermRedirect TracThemeEngine
> Initenv for '/var/lib/jenkins/jobs/bh-trac-test/workspace/installer/bloodhound/environments/main'
> failed.
> Wrong number of arguments: 3
> Traceback (most recent call last):
> File "bloodhound_setup.py", line 379, in <module>
> bsetup.setup()
> File "bloodhound_setup.py", line 192, in setup
> self.writeconfig(baseini, [BASE_CONFIG, accounts_config])
> File "bloodhound_setup.py", line 242, in writeconfig
> config.save()
> File "/var/lib/jenkins/jobs/bh-trac-test/workspace/trac/trac/config.py",
> line 237, in save
> with AtomicFile(self.filename, 'w') as fileobj:
> File "/var/lib/jenkins/jobs/bh-trac-test/workspace/trac/trac/util/__init__.py",
> line 171, in __init__
> (fd, self._temp) = tempfile.mkstemp(prefix=name + '-', dir=dir)
> File "/usr/lib/python2.6/tempfile.py", line 293, in mkstemp
> return _mkstemp_inner(dir, prefix, suffix, flags)
> File "/usr/lib/python2.6/tempfile.py", line 228, in _mkstemp_inner
> fd = _os.open(file, flags, 0600)
> OSError: [Errno 2] No such file or directory:
> '/var/lib/jenkins/jobs/bh-trac-test/workspace/installer/bloodhound/environments/main/conf/base.ini-hUfPj7'
> }}}
>
> Considering the fact that there's no Trac environment at the moment ,
> it seems that the problem is related to the number of parameters
> supplied in to trac-admin command . I reviewed the code in console.py
> file (more precisely `TracAdmin.do_initenv` ) and it seems changes
> sketched in this patch [2]_ for #85 (... and enhanced later by Gary
> ...) have not been applied in trunk ?
>
> Could you please check ?
> This seems to be a critical bug afaics
>
> I'll setup something similar for the installer instead of svn co of trunk
>
> .. [1] Jenkins » bh-trac-test » #44 » Console Output
> (http://hudson.testrun.org/job/bh-trac-test/44/console)
>
> .. [2] Patch: BH Trac #85 : Option in trac-admin initenv cmd to
> prevent loading default wiki pages (optional)
> (https://issues.apache.org/bloodhound/attachment/ticket/85/t85_r1357341_initenv_nodocs.diff)
>
>
> On 8/3/12, Gary Martin <ga...@wandisco.com> wrote:
>> Greg,
>>
>> That is a good idea. I was thinking of possibly using buildbot to do
>> that job as well. Of course, if a dist script is created it can always
>> just call that instead so you idea probably provides the best basic
>> solution. I believe you did mention one release process script from
>> subversion so I will investigate that. Thanks.
>>
>> Olemis,
>>
>> My buildbot master.cfg needs a bit of redacting so I will try to fix
>> that and commit it to the repository for others to suggest improvements
>> by Monday or Tuesday. Anyway, I believe that this is a relevant snippet
>> from my code:
>>
>> instdir = os.path.join("build", "installer")
>> env = {'PATH': os.path.abspath("build/installer/bloodhound/bin") +
>> ":${PATH}",
>> 'PYTHONPATH':
>> os.path.abspath("build/installer/bloodhound/lib/python2.7")}
>> envdir = 'bloodhound'
>> pip = os.path.join(envdir, 'bin', 'pip')
>>
>> factory.addStep(ShellCommand(command=["virtualenv",
>> "--no-site-packages", envdir], workdir=instdir, name="install
>> virtualenv"))
>> factory.addStep(ShellCommand(command=[pip, 'install', '-r',
>> reqsfile], workdir=instdir, env=env, name="install packages"))
>> factory.addStep(ShellCommand(command=[python, 'bloodhound_setup.py',
>> '-d', 'sqlite',
>> '--admin-user=' + adminuser,
>> '--admin-password=' + adminpassword], workdir=instdir, name="setup"))
>>
>> steps after this were all tests of one sort or another followed by a
>> removal of the bloodhound directory for a bit of cleanup just in case
>> the buildslave is persistent.
>>
>> Cheers,
>> Gary
>>
>>
>> On 08/03/2012 07:31 AM, Greg Stein wrote:
>>> I'd also recommend creating a "dist.sh" script for assembling the
>>> tarball. For example, I queried if the wireframes should be
>>> distributed, and the answer was "no". That implies that assembling the
>>> tarball requires an "rm" step somewhere after the "svn export". It
>>> would be nice to script that, rather than following a list of manual
>>> steps.
>>>
>>> I believe that I've posted example dist.sh types of scripts, but would
>>> be happy to repost if needed.
>>>
>>> Cheers,
>>> -g
>>>
>>> On Fri, Aug 3, 2012 at 12:26 AM, Olemis Lang <ol...@gmail.com> wrote:
>>>> could you share your build script , please ?
>>>>
>>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>> On 02/08/12 01:57, Olemis Lang wrote:
>>>>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>>>>> Just for the record, I have downloaded reviewed the files to my
>>>>>>>> technical
>>>>>>>> ability.
>>>>>>>>
>>>>>>>> +1 for the release from me.
>>>>>>>>
>>>>>> I second that . The only thing I can mention is that even if manual
>>>>>> installation procedure works for me , on the other hand all the
>>>>>> attempts I made so as to install it from tarball in a Jenkins build
>>>>>> job have failed . This is mainly because :
>>>>>>
>>>>>> 1. I'm not a proficient Jenkins user ...
>>>>>> 2. it seems there's an issue with virtualenv somewhere and ...
>>>>>> 3. I've not been able to dedicate any time to this task after the
>>>>>> few initial experiments
>>>>> I appear to have been able to get things going with Buildbot with the
>>>>> virtualenv instructions, although I am not convinced that you can
>>>>> really
>>>>> activate the virtualenv in a buildstep. I didn't try this and instead
>>>>> resorted to a bit of trickery through which python binary was used
>>>>> after
>>>>> virtualenv creation.
>>>>>
>>>>> To be fair, there is no specific need to use virtualenv, as long as you
>>>>> have a fresh environment each time. My attempts so far have not been
>>>>> with throwaway VMs. Of course, I am sure that there will be other ways
>>>>> to isolate a python environment.
>>>>>
>>>>> Cheers,
>>>>> Gary
>>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Olemis.
>>>>
>>>> Blog ES: http://simelo-es.blogspot.com/
>>>> Blog EN: http://simelo-en.blogspot.com/
>>>>
>>>> Featured article:
>>
>
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
u r a genius !
That works for me too . Now all dependencies are installed
:)
Nonetheless , I noticed something is happening in there [1]_ . AFAICS
an error is raised when Trac environment is created and installer
configuration saved . Details follow
{{{
Successfully installed Babel BloodhoundDashboardPlugin
BloodhoundMultiProduct BloodhoundTheme Genshi Pygments pytz Trac
TracAccountManager TracPermRedirect TracThemeEngine
Initenv for '/var/lib/jenkins/jobs/bh-trac-test/workspace/installer/bloodhound/environments/main'
failed.
Wrong number of arguments: 3
Traceback (most recent call last):
File "bloodhound_setup.py", line 379, in <module>
bsetup.setup()
File "bloodhound_setup.py", line 192, in setup
self.writeconfig(baseini, [BASE_CONFIG, accounts_config])
File "bloodhound_setup.py", line 242, in writeconfig
config.save()
File "/var/lib/jenkins/jobs/bh-trac-test/workspace/trac/trac/config.py",
line 237, in save
with AtomicFile(self.filename, 'w') as fileobj:
File "/var/lib/jenkins/jobs/bh-trac-test/workspace/trac/trac/util/__init__.py",
line 171, in __init__
(fd, self._temp) = tempfile.mkstemp(prefix=name + '-', dir=dir)
File "/usr/lib/python2.6/tempfile.py", line 293, in mkstemp
return _mkstemp_inner(dir, prefix, suffix, flags)
File "/usr/lib/python2.6/tempfile.py", line 228, in _mkstemp_inner
fd = _os.open(file, flags, 0600)
OSError: [Errno 2] No such file or directory:
'/var/lib/jenkins/jobs/bh-trac-test/workspace/installer/bloodhound/environments/main/conf/base.ini-hUfPj7'
}}}
Considering the fact that there's no Trac environment at the moment ,
it seems that the problem is related to the number of parameters
supplied in to trac-admin command . I reviewed the code in console.py
file (more precisely `TracAdmin.do_initenv` ) and it seems changes
sketched in this patch [2]_ for #85 (... and enhanced later by Gary
...) have not been applied in trunk ?
Could you please check ?
This seems to be a critical bug afaics
I'll setup something similar for the installer instead of svn co of trunk
.. [1] Jenkins » bh-trac-test » #44 » Console Output
(http://hudson.testrun.org/job/bh-trac-test/44/console)
.. [2] Patch: BH Trac #85 : Option in trac-admin initenv cmd to
prevent loading default wiki pages (optional)
(https://issues.apache.org/bloodhound/attachment/ticket/85/t85_r1357341_initenv_nodocs.diff)
On 8/3/12, Gary Martin <ga...@wandisco.com> wrote:
> Greg,
>
> That is a good idea. I was thinking of possibly using buildbot to do
> that job as well. Of course, if a dist script is created it can always
> just call that instead so you idea probably provides the best basic
> solution. I believe you did mention one release process script from
> subversion so I will investigate that. Thanks.
>
> Olemis,
>
> My buildbot master.cfg needs a bit of redacting so I will try to fix
> that and commit it to the repository for others to suggest improvements
> by Monday or Tuesday. Anyway, I believe that this is a relevant snippet
> from my code:
>
> instdir = os.path.join("build", "installer")
> env = {'PATH': os.path.abspath("build/installer/bloodhound/bin") +
> ":${PATH}",
> 'PYTHONPATH':
> os.path.abspath("build/installer/bloodhound/lib/python2.7")}
> envdir = 'bloodhound'
> pip = os.path.join(envdir, 'bin', 'pip')
>
> factory.addStep(ShellCommand(command=["virtualenv",
> "--no-site-packages", envdir], workdir=instdir, name="install
> virtualenv"))
> factory.addStep(ShellCommand(command=[pip, 'install', '-r',
> reqsfile], workdir=instdir, env=env, name="install packages"))
> factory.addStep(ShellCommand(command=[python, 'bloodhound_setup.py',
> '-d', 'sqlite',
> '--admin-user=' + adminuser,
> '--admin-password=' + adminpassword], workdir=instdir, name="setup"))
>
> steps after this were all tests of one sort or another followed by a
> removal of the bloodhound directory for a bit of cleanup just in case
> the buildslave is persistent.
>
> Cheers,
> Gary
>
>
> On 08/03/2012 07:31 AM, Greg Stein wrote:
>> I'd also recommend creating a "dist.sh" script for assembling the
>> tarball. For example, I queried if the wireframes should be
>> distributed, and the answer was "no". That implies that assembling the
>> tarball requires an "rm" step somewhere after the "svn export". It
>> would be nice to script that, rather than following a list of manual
>> steps.
>>
>> I believe that I've posted example dist.sh types of scripts, but would
>> be happy to repost if needed.
>>
>> Cheers,
>> -g
>>
>> On Fri, Aug 3, 2012 at 12:26 AM, Olemis Lang <ol...@gmail.com> wrote:
>>> could you share your build script , please ?
>>>
>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 02/08/12 01:57, Olemis Lang wrote:
>>>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>>>> Just for the record, I have downloaded reviewed the files to my
>>>>>>> technical
>>>>>>> ability.
>>>>>>>
>>>>>>> +1 for the release from me.
>>>>>>>
>>>>> I second that . The only thing I can mention is that even if manual
>>>>> installation procedure works for me , on the other hand all the
>>>>> attempts I made so as to install it from tarball in a Jenkins build
>>>>> job have failed . This is mainly because :
>>>>>
>>>>> 1. I'm not a proficient Jenkins user ...
>>>>> 2. it seems there's an issue with virtualenv somewhere and ...
>>>>> 3. I've not been able to dedicate any time to this task after the
>>>>> few initial experiments
>>>> I appear to have been able to get things going with Buildbot with the
>>>> virtualenv instructions, although I am not convinced that you can
>>>> really
>>>> activate the virtualenv in a buildstep. I didn't try this and instead
>>>> resorted to a bit of trickery through which python binary was used
>>>> after
>>>> virtualenv creation.
>>>>
>>>> To be fair, there is no specific need to use virtualenv, as long as you
>>>> have a fresh environment each time. My attempts so far have not been
>>>> with throwaway VMs. Of course, I am sure that there will be other ways
>>>> to isolate a python environment.
>>>>
>>>> Cheers,
>>>> Gary
>>>>
>>>
>>> --
>>> Regards,
>>>
>>> Olemis.
>>>
>>> Blog ES: http://simelo-es.blogspot.com/
>>> Blog EN: http://simelo-en.blogspot.com/
>>>
>>> Featured article:
>
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Gary Martin <ga...@wandisco.com>.
Greg,
That is a good idea. I was thinking of possibly using buildbot to do
that job as well. Of course, if a dist script is created it can always
just call that instead so you idea probably provides the best basic
solution. I believe you did mention one release process script from
subversion so I will investigate that. Thanks.
Olemis,
My buildbot master.cfg needs a bit of redacting so I will try to fix
that and commit it to the repository for others to suggest improvements
by Monday or Tuesday. Anyway, I believe that this is a relevant snippet
from my code:
instdir = os.path.join("build", "installer")
env = {'PATH': os.path.abspath("build/installer/bloodhound/bin") +
":${PATH}",
'PYTHONPATH':
os.path.abspath("build/installer/bloodhound/lib/python2.7")}
envdir = 'bloodhound'
pip = os.path.join(envdir, 'bin', 'pip')
factory.addStep(ShellCommand(command=["virtualenv",
"--no-site-packages", envdir], workdir=instdir, name="install
virtualenv"))
factory.addStep(ShellCommand(command=[pip, 'install', '-r',
reqsfile], workdir=instdir, env=env, name="install packages"))
factory.addStep(ShellCommand(command=[python, 'bloodhound_setup.py',
'-d', 'sqlite',
'--admin-user=' + adminuser,
'--admin-password=' + adminpassword], workdir=instdir, name="setup"))
steps after this were all tests of one sort or another followed by a
removal of the bloodhound directory for a bit of cleanup just in case
the buildslave is persistent.
Cheers,
Gary
On 08/03/2012 07:31 AM, Greg Stein wrote:
> I'd also recommend creating a "dist.sh" script for assembling the
> tarball. For example, I queried if the wireframes should be
> distributed, and the answer was "no". That implies that assembling the
> tarball requires an "rm" step somewhere after the "svn export". It
> would be nice to script that, rather than following a list of manual
> steps.
>
> I believe that I've posted example dist.sh types of scripts, but would
> be happy to repost if needed.
>
> Cheers,
> -g
>
> On Fri, Aug 3, 2012 at 12:26 AM, Olemis Lang <ol...@gmail.com> wrote:
>> could you share your build script , please ?
>>
>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>> On 02/08/12 01:57, Olemis Lang wrote:
>>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>>> Just for the record, I have downloaded reviewed the files to my
>>>>>> technical
>>>>>> ability.
>>>>>>
>>>>>> +1 for the release from me.
>>>>>>
>>>> I second that . The only thing I can mention is that even if manual
>>>> installation procedure works for me , on the other hand all the
>>>> attempts I made so as to install it from tarball in a Jenkins build
>>>> job have failed . This is mainly because :
>>>>
>>>> 1. I'm not a proficient Jenkins user ...
>>>> 2. it seems there's an issue with virtualenv somewhere and ...
>>>> 3. I've not been able to dedicate any time to this task after the
>>>> few initial experiments
>>> I appear to have been able to get things going with Buildbot with the
>>> virtualenv instructions, although I am not convinced that you can really
>>> activate the virtualenv in a buildstep. I didn't try this and instead
>>> resorted to a bit of trickery through which python binary was used after
>>> virtualenv creation.
>>>
>>> To be fair, there is no specific need to use virtualenv, as long as you
>>> have a fresh environment each time. My attempts so far have not been
>>> with throwaway VMs. Of course, I am sure that there will be other ways
>>> to isolate a python environment.
>>>
>>> Cheers,
>>> Gary
>>>
>>
>> --
>> Regards,
>>
>> Olemis.
>>
>> Blog ES: http://simelo-es.blogspot.com/
>> Blog EN: http://simelo-en.blogspot.com/
>>
>> Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Greg Stein <gs...@gmail.com>.
I'd also recommend creating a "dist.sh" script for assembling the
tarball. For example, I queried if the wireframes should be
distributed, and the answer was "no". That implies that assembling the
tarball requires an "rm" step somewhere after the "svn export". It
would be nice to script that, rather than following a list of manual
steps.
I believe that I've posted example dist.sh types of scripts, but would
be happy to repost if needed.
Cheers,
-g
On Fri, Aug 3, 2012 at 12:26 AM, Olemis Lang <ol...@gmail.com> wrote:
> could you share your build script , please ?
>
> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>
>> On 02/08/12 01:57, Olemis Lang wrote:
>>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>>> Just for the record, I have downloaded reviewed the files to my
>>>>> technical
>>>>> ability.
>>>>>
>>>>> +1 for the release from me.
>>>>>
>>> I second that . The only thing I can mention is that even if manual
>>> installation procedure works for me , on the other hand all the
>>> attempts I made so as to install it from tarball in a Jenkins build
>>> job have failed . This is mainly because :
>>>
>>> 1. I'm not a proficient Jenkins user ...
>>> 2. it seems there's an issue with virtualenv somewhere and ...
>>> 3. I've not been able to dedicate any time to this task after the
>>> few initial experiments
>>
>> I appear to have been able to get things going with Buildbot with the
>> virtualenv instructions, although I am not convinced that you can really
>> activate the virtualenv in a buildstep. I didn't try this and instead
>> resorted to a bit of trickery through which python binary was used after
>> virtualenv creation.
>>
>> To be fair, there is no specific need to use virtualenv, as long as you
>> have a fresh environment each time. My attempts so far have not been
>> with throwaway VMs. Of course, I am sure that there will be other ways
>> to isolate a python environment.
>>
>> Cheers,
>> Gary
>>
>
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
Re: CI and virtualenv (Was: Re: [VOTE] Release Apache Bloodhound
0.1.0 (incubating) (RC1))
Posted by Olemis Lang <ol...@gmail.com>.
could you share your build script , please ?
On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>
> On 02/08/12 01:57, Olemis Lang wrote:
>> On 8/1/12, Gary Martin <ga...@wandisco.com> wrote:
>>> On 30/07/12 12:48, Joachim Dreimann wrote:
>>>> Just for the record, I have downloaded reviewed the files to my
>>>> technical
>>>> ability.
>>>>
>>>> +1 for the release from me.
>>>>
>> I second that . The only thing I can mention is that even if manual
>> installation procedure works for me , on the other hand all the
>> attempts I made so as to install it from tarball in a Jenkins build
>> job have failed . This is mainly because :
>>
>> 1. I'm not a proficient Jenkins user ...
>> 2. it seems there's an issue with virtualenv somewhere and ...
>> 3. I've not been able to dedicate any time to this task after the
>> few initial experiments
>
> I appear to have been able to get things going with Buildbot with the
> virtualenv instructions, although I am not convinced that you can really
> activate the virtualenv in a buildstep. I didn't try this and instead
> resorted to a bit of trickery through which python binary was used after
> virtualenv creation.
>
> To be fair, there is no specific need to use virtualenv, as long as you
> have a fresh environment each time. My attempts so far have not been
> with throwaway VMs. Of course, I am sure that there will be other ways
> to isolate a python environment.
>
> Cheers,
> Gary
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article: