Re: update on the next release (and a suggestion)
> I am very interested in a few of the new features (e.g. SVNPoller,
> FileUp/Download and have tested them in my test environment. Also
> the trial tests pass without any errors on my GNU/Debian machine.
>
> Therefore I would like to ask if you could give us a hint when the next
> version will be out.
Very soon now. The reconfiguring-builders fix was the last big issue, which I
finally got done about a week ago. The only thing left on my list is to clean
up file upload/download a little bit (specifically adding some helpful error
messages if the slave is too old or if the target file cannot be found). My
current goal is to cut the release this coming weekend.
> Another question is, that I would have found it nice to specify the
> attributes for a downloaded file, as I would like to download some test
> scripts which have to be executed on the slave.
So something like FileDownload(source, dest, mode=0755) ? Sure, I'd accept a
patch for that, after 0.7.5 is out. Don't write it just yet, as I'll probably
be changing FileDownload a little bit before the release, but as soon as
0.7.5 is cut feel free to submit one.
> And I would prefer to specify in a Shell step "./my_bash.sh", instead of [
> "/bin/bash", "my_bash.sh"].
If my_bash.sh has the executable bit set, then command=["./my_bash.sh"] ought
to work (assuming it has a #!/bin/bash line, of course).
> Would you accept patches for this? Or do you consider it a too big security
> risk?
I guess I should settle on how ShellCommands should be specified. I've
certainly had cases myself where I want to use shell metacharacters, things
like "scp ../*.deb host:~/public_html/" and similar. My hunch is that things
like that belong in a Makefile rather than in the Buildbot, and making it
difficult or annoying to use the full power of bash within ShellCommands is a
sort of passive/aggressive way to accomplish that :).
There's not necessarily a security risk in string-based commands. The risk
comes when you are interpolating other strings into them, specifically
strings that come from a hostile party, where you get injection attacks and
games with passing shell metacharacters in through a string that was
"supposed" to be something simple. If you can only use argv array-based
ShellCommands, these threats are a lot less severe. But there aren't a whole
lot of places where we interpolate things into a string-based command
anyways, unless you're using WithProperties a lot.
Would it make sense for this test script that you want to download and
execute on the slave instead be checked in to your source tree? I'd like to
understand the use case a bit more before coming to a decision about whether
to encourage or discourage string-based commands.
[note: by "string-base commands" I mean something like
ShellCommand(command="ls *.foo >stuff.txt") . When you pass a non-array to
command=, the buildslave pretends you had written command=["/bin/sh", "-c",
"ls *.foo >stuff.txt"] instead.]
cheers,
-Brian
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
RSS Feed