Yes I agree in theory, but since everyone should be able to run the unit tests, I didn't want to require the fact that localhost can be accessed via ssh.. So unless I find a good clean way to do it in setup_module directly in the test file (that works on linux and osx) it's probably better to do the run-local dance..
2013/1/30 Todd DeLuca <[email protected]>: > I find that my fabfiles are much cleaner when I use 'run', etc., to connect > to localhost instead of switching between 'run' and 'local' depending on > whether or not I am connecting to localhost. Here are my notes for setting > up my Mac so that I can ssh into it from localhost. My friends tease me > about sshing into localhost from localhost but they just don't understand. > :-) > > ## Enable the ssh daemon, sshd, on Mac OS X > > How to: > http://osxdaily.com/2011/09/30/remote-login-ssh-server-mac-os-x/ > > On my mac laptop, here is how I enabled remote logins via ssh: > > 1. Go to System Preferences > 2. Choose Sharing > 3. Select Remote login, and optionally specify all users or specific users. > > > ## Use a key-pair to avoid typing your password over and over again. > > Generate ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub using `ssh-keygen` or the like. > > Add ~/.ssh/id_dsa.pub to ~/.ssh/authorized_keys > > cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys > > Fix the permissions on your files and dirs. SSH is finicky about > permissions. > In my experience it expects files and dirs to be writable only by you and > readable by either only you (for private keys, etc.) or by anyone (for > public > keys, etc.): > > chmod 755 ~ > chmod 700 ~/.ssh > chmod 600 ~/.ssh/id_dsa > chmod 644 ~/.ssh/id_dsa.pub > chmod 600 ~/.ssh/authorized_keys > > > Regards, > Todd > > > > On Wed, Jan 30, 2013 at 8:17 AM, andrea crotti <[email protected]> > wrote: >> >> Yes I tried that but than I need to setup some ssh keys to connect >> automatically to localhost (unless there is a smarter way to do that). >> >> 2013/1/30 Jasper van den Bosch <[email protected]>: >> > Yes, or just specify localhost as the host. We could think about making >> > a >> > fully mocked version of the fabric API as a python package. >> > >> > >> > On 30 January 2013 14:11, andrea crotti <[email protected]> >> > wrote: >> >> >> >> Well I suppose it's files.exists, and in fact adding the other mock >> >> works >> >> >> >> def files_exists(): >> >> >> >> m = Mock() >> >> >> >> m.exists = lambda x: True >> >> >> >> return m >> >> >> >> @patch('fabfile.files', new=files_exists()) >> >> >> >> It would be nice to avoid mocking all the calls though.. >> >> And maybe another useful thing would be to make something that should >> >> run >> >> on different servers run locally, I suppose I could simply do a >> >> run -> local >> >> translation, right? >> >> >> >> On 30 Jan 2013 12:58, "Jasper van den Bosch" <[email protected]> wrote: >> >>> >> >>> Hi andrea, >> >>> >> >>> I regularly unit-test fabric code. If you are mocking out run() etc, >> >>> and >> >>> using the regular python executable, not fab, to start the tests, I >> >>> don't >> >>> see why it would try to connect. Can you post more code, i.e. as a >> >>> Gist? >> >>> >> >>> Jasper >> >>> >> >>> On 30 January 2013 13:30, andrea crotti <[email protected]> >> >>> wrote: >> >>>> >> >>>> I'm trying to unit test my fabfile, what I would like to do is the >> >>>> following: >> >>>> - set some conditions >> >>>> - get a trail of commands that would be run >> >>>> - check if that is correct >> >>>> >> >>>> Now the problem is that for any command it still wants to connect, so >> >>>> even if I mock out run, it still complains about the host missing for >> >>>> some reason. >> >>>> >> >>>> And then I have to find a way to record the sequence of commands >> >>>> instead of simply printing them out, any ideas about that? >> >>>> By the way, I was looking for documentation about unit testing and >> >>>> fabric but didn't find anything useful, is noone doing it? >> >>>> >> >>>> Test: >> >>>> def fake_run(cmd): >> >>>> return sys.stdout.write(cmd) >> >>>> >> >>>> @patch('fabfile.env.hosts', new=['localhost']) >> >>>> @patch('fabfile.WAZOKU_REPO', new='/tmp/wazoku') >> >>>> @patch('fabfile.run', new=fake_run) >> >>>> class TestNewDeploy(unittest.TestCase): >> >>>> def test_first_run_works_file(self): >> >>>> >> >>>> >> >>>> Function to test: >> >>>> @parallel >> >>>> def deploy_head_new_pull(branch='master'): >> >>>> api_dir = "%s/company-api/api" % COMPANY_REPO >> >>>> ve_dir = '%s/ve' % api_dir >> >>>> if not files.exists(COMPANY_REPO): >> >>>> run(CLONE.format(branch, COMPANY_REPO)) >> >>>> # create the symlink to make sure it points to the >> >>>> right >> >>>> place >> >>>> run('ln -sf %s/company-api $HOME/api' % COMPANY_REPO) >> >>>> run('virtualenv %s' % ve_dir) >> >>>> else: >> >>>> with cd(COMPANY_API): >> >>>> run('git pull') >> >>>> run('git clean -f') >> >>>> >> >>>> with settings(user='company'): >> >>>> with cd(COMPANY_REPO): >> >>>> run('source %s/bin/activate && pip install -r >> >>>> requirements.txt' % ve_dir) >> >>>> run('cp production_settings.py settings.py') >> >>>> >> >>>> restart_api() >> >>>> >> >>>> _______________________________________________ >> >>>> Fab-user mailing list >> >>>> [email protected] >> >>>> https://lists.nongnu.org/mailman/listinfo/fab-user >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Jasper van den Bosch >> >>> ilogue.com/jasper >> >>> >> >>> I'd love to see your attachment, but please use OpenDocument, not a >> >>> proprietary format like docx. It's an international standard, endorsed >> >>> by >> >>> the EU, and implemented in many office suites, such as LibreOffice, >> >>> and >> >>> commercial products from Oracle, Sun, IBM and Microsoft (from 2007). >> > >> > >> > >> > >> > -- >> > Jasper van den Bosch >> > ilogue.com/jasper >> > >> > I'd love to see your attachment, but please use OpenDocument, not a >> > proprietary format like docx. It's an international standard, endorsed >> > by >> > the EU, and implemented in many office suites, such as LibreOffice, and >> > commercial products from Oracle, Sun, IBM and Microsoft (from 2007). >> >> _______________________________________________ >> Fab-user mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/fab-user > > > > > -- > Todd DeLuca > http://todddeluca.com > http://wall.hms.harvard.edu/ > _______________________________________________ Fab-user mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/fab-user
