----- Original Message -----
> host.run('rm -rf %s; mkdir -p %s' % (dir_, dir_))
> host.send_file(dir_, dir_)
The delete_dest=True argument for autotest host.send_file() attempts
to
handle this for us. In fact, they use the same/similar commands that
you list above.
delete_dest: if this is true, the command will also clear
out any old files at dest that are not in the
source
I didn't do exhaustive testing to ensure that delete_dest was honored,
but can queue that up shortly. I'd like to have the built-in autotest
delete_dest= support working, but we can certainly use the above if
the
autotest support is broken or not patchable in the short-term.
It's simple. Try to do:
host.send_file('/etc/autoqa', '/etc/autoqa', delete_dest=True)
This won't work with rsync, it will create /etc/autoqa/autoqa even
if the destination doesn't exist. On the other hand, it will work
with scp if the destination doesn't exist, but it won't work if
the destination does exist (it will create /etc/autoqa/autoqa).
So let's try:
host.send_file('/etc/autoqa/', '/etc/autoqa/', delete_dest=True)
This will work with rsync in both cases (destination exists and
doesn't exist). But scp will fail if the destination doesn't exist.
Broooken! :-)
The easiest workaround is to remove and re-create the destination
manually and always use slashes.
How about just using packaging instead of recreating all the
"packaging"
tasks manually. Seems like it would be beneficial to only maintain one
"packaging" scenario. My assumption with the original patch was that
all code would be packaged and published in a repo somewhere, even for
a
staging instance. For staging code, some cronjob would git checkout,
attempt a build and update the 'testing' repo [1] with the build
results. This mimics the behavior for official Fedora updates and lets
existing mechanisms deal with packaging.
The goal with the original patchset was from an idea you gave me.
Basically, making it *really* effortless to add a new system and start
scheduling tests to it. I was able to hide all the package install and
configuration into the site_autotest.py. While it seemed to work, I'm
not convinced we want to put all AutoQA setup into this method. I
liked
it, but as coded, anyone with the autoqa and autotest-server packages
installed will get autoqa installed+configured on *all* of their test
clients. I may need to make this support optional by way of a
global_config.ini setting.
I can imagine this could work just fine for production and
staging environment. But there is one use case missing, and that
is the development environment. Basically, when I'm developing
AutoQA on my server+client(s), I don't want to replicate every
change I make onto all those machines. That's really tedious.
Also I'm often quite confused where to make this change (on the
server/on the client/on all machines). It depends on which part
of AutoQA I'm currently working on (hooks/harness/library/tests).
My dream is to do any change on the server only, and it gets
propagated to all clients. I can do that using rsync, but yes,
it's not as clean as using rpm packages (which you can't use
for development anyway).
I'll have to think more about it, tomorrow.
So my recommendation would be ...
1. Adjust autotest-server %requires to add rsync and
openssh-{clients,server}
Actually only the autotest client requires openssh-server. (But it is
kind of obvious because you need to register it with the server and
for that you need openssh-server installed.)
Both the server and the client require openssh-clients (and preferably
also rsync).