linaro-validation

linaro-validation@lists.linaro.org

818 discussions

by Milo Casagrande

Hello everyone, one of the discussion we had during connect was to find (and use) a common testing framework for unit (and maybe beyond) tests. What we should use is probably a framework that still supports all the unittest based tests we already have in our projects. Following also other people suggestions, I looked around and did some initial tests. What follows is a list of what we could use: - pytest: http://pytest.org/latest/ - nose: https://nose.readthedocs.org/en/latest/ - stick with Python provided unittest: no need to install anything else Personally I do not dislike unittest even if of the three is the most verbose, but pytest is a powerful handy tool and easier to use (you don't even need to inherit from TestCase). I didn't play with pytest and Django tests, but looks like it is possible to easily integrate it: http://pytest-django.readthedocs.org/en/latest/ Tools: These kind of tools are more targeted at mocking/patching objects or behavior, should we avoid them or use them? (no flame wars please! :-) Personally I find that sometimes (probably too often) I need them. If we need them we should suggest which one to use, and stick with it: - mock: http://www.voidspace.org.uk/python/mock/ - mocker: https://pypi.python.org/pypi/mocker There are more, but these two are the ones I know about or have been using. Other suggestions? Ciao! -- Milo Casagrande | Automation Engineer Linaro.org <www.linaro.org> │ Open source software for ARM SoCs

12 years, 10 months

PEP8 checker variability

by Neil Williams

At LCE13, we proposed to check code against PEP8 (http://cards.linaro.org/browse/LAVA-485) prior to merges and the initial thought was that we could just rely on PyCharm to show the code as "all green" to achieve PEP8 compatibility. Turns out that PyCharm doesn't restrict itself to PEP8 and can override PEP8 with project-specific settings in some areas (typically line length). Line length is actually a bit awkward in places and I've been using the default PyCharm length of 120 whilst PEP8 advises 79. To keep the code readable, this could involve a number of new single-use sub-routines to reduce the indenting. Is this worth doing? If not, we can look at a project-specific [pep8] setting in setup.py. Other tools for PEP8 include pep8 itself, pylint and pychecker. The command line pep8 has various false positives and false negatives in it's bug history, so we may all have to run the same version and then mandate that version when others test the code too. pylint disagrees with pep8 and PyCharm on what is an error (e.g. line length 80). pychecker is more of a source code checker and it tries to import all modules before checking which can lead to errors. e.g. when checking my multinode files, it complained about missing SSL imports when there is no such warning when running the code or in PyCharm. PyCharm itself includes it's own error checking on top of PEP8 and merges PEP8 with PyCharm's own validation output. e.g. mutable default arguments raise a warning of the same type as a PEP8 warning: lava_dispatcher/actions/lava_android_test.py def run(self, commands=[], command_file=None, parser=None, timeout=-1): needs to become: def run(self, commands=None, command_file=None, parser=None, timeout=-1): if not commands: commands = [] Arguably, this is probably a correct change, but there are other situations where PyCharm appears to get it wrong: e.g. in lava_dispatcher/signals/__init__.py (a file which has had lots of changes in MultiNode). PyCharm thinks that this (working) code is an error: def signal(self, name, params, context=None): self.context = context handler = getattr(self, '_on_' + name, None) if not handler and self._cur_handler: handler = self._cur_handler.custom_signal params = [name] + list(params) if handler: try: handler(*params) except: logging.exception("handling signal %s failed", name) PyCharm complains of two things here. handler: "'object' object is not callable" and except: "Too broad exception clause". The exception warning is a "weak warning" in PyCharm and wouldn't stop the code getting a "green light". However, the handler code works just fine and it's not clear to me how to change the code to add a __call__ function which will reference the correct handler. Most of the changes I have considered are quite intrusive for this part of the code. We could document these as "overrides" using a comment but that won't change how PyCharm shows the file, yet this "error" has nothing to do with PEP8 AFAICT. How intrusive do we want to go for PEP8? PyCharm isn't going to be the PEP8 checker used during packaging or deployment, so what checker are we going to use and how? -- Neil Williams ============= http://www.linux.codehelp.co.uk/

12 years, 10 months

testing dispatcher code changes

by James Tunnicliffe

Hi, I am trying to get a couple of new device types into LAVA. I have a new config file in a checkout of lava-dispatcher, which is linked in <instance>/code/current. Path to code I want to run: /srv/lava/instances/lab/code/current/local/lava-dispatcher/lava_dispatcher/default-config/lava-dispatcher/device-types/ Running bin/buildout in /srv/lava/instances/lab/code/current/ The new code isn't ending up in /srv/lava/.cache/branch-cache/lava-dispatcher/checkouts. Clearly I am missing something! Any ideas? -- James Tunnicliffe

12 years, 10 months

About the adb command on LAVA

by YongQin Liu

Hi, All >From this file: http://bazaar.launchpad.net/~linaro-validation/lava-lab/salt-states/view/he… we can see that the /usr/local/bin/adb file should be a symbolic of /usr/ local/android-sdk-linux/platform-tools/adb but now it's a normal file(the adb wrapper before): liuyq0307@fastmodels01:~$ ll `which adb` -rwxr-xr-x 1 root root 877 May 31 03:54 /usr/local/bin/adb* liuyq0307@fastmodels01:~$ Anyone know where is wrong? -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/pipermail/linaro-validation

12 years, 10 months

LAVA prompt and boot complete matches

by James Tunnicliffe

Hi, I have a board here that doesn't boot to a prompt, it boots, but you don't get a prompt until you hit enter. At that point it is the most basic sh prompt (# ). I am hoping to get the developer to get it to a prompt, but until then it would be good to work around that if I can. I imagine LAVA uses a regexp to detect when a board has booted, but I can't find it in the source. Is it waiting for the command prompt or can I apply some expect style scripting? Do I need a prompt in a specific form for testing? I have seen LAVA with the return code of the previous command in the prompt before, but don't know if I need to get images set up to do that or if I can script setting that up as part of a test or boot process. Thanks, -- James Tunnicliffe

12 years, 10 months

v.l.o Downtime

by Dave Pigott

Hi all, We need to start the switch over from launchpad single sign on, and to do this there will need to be a very small downtime of the LAVA server - it should be less than 5 minutes, maybe less than a minute if I do it right. I intend to do this on Wednesday at 11:00UTC (12:00BST). I would do it tomorrow, but I have a doctor's appointment in the morning. Thanks for your patience Dave

12 years, 10 months

Re: [Linaro-validation] Could you please help to review the MP?

by YongQin Liu

Hi, All Anyone can help to review the following MP? https://code.launchpad.net/~liuyq0307/lava-dispatcher/kill-process-using-br… We need to merge and deploy it to production as soon as possible. the rtsm_ve-armv8_05<https://validation.linaro.org/lava-server/scheduler/device/rtsm_ve-armv8_05> device also has the same problem. Thanks, Yongqin Liu On 16 July 2013 10:18, YongQin Liu <yongqin.liu(a)linaro.org> wrote: > Hi, Senthil > > Could you help to review the following MP, > > https://code.launchpad.net/~liuyq0307/lava-dispatcher/kill-process-using-br… > > It is supported to resolve the bug reported here: > https://bugs.launchpad.net/lava-dispatcher/+bug/1201491 > > -- > Thanks, > Yongqin Liu > --------------------------------------------------------------- > #mailing list > linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/linaro-android > linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> > http://lists.linaro.org/pipermail/linaro-validation > -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/pipermail/linaro-validation

12 years, 10 months

Going beyond the Django ORM limitations with Postgres

by Michael Hudson-Doyle

Hey Lava devs, I realise that right now might not be the best time in the development cycle to mention this, but I've just watched an interesting talk on really using postgres with Django: http://www.youtube.com/watch?v=S-kbfpRpVsY In particular, I think the (already postgres-specific) horrific code I wrote for matching tags on job dispatch could be replaced with simple tags arrays on Job and Device and a "<@" operator. There are some other bits that could potentially be used (e.g. the JSON stuff, maybe hstore for test results) but this part jumped out at me! Cheers, mwh

12 years, 10 months

Staging down time

by Dave Pigott

Hi all, We need to take staging down for a while to move it from it's current cloud node to the master node, so that we can release a node from the cloud so that the multi-node dispatcher can run on bare metal. I plan to do the migration tomorrow morning starting at 08:00UTC. If all goes well, staging should be back up before 12:00UTC. If anyone knows a reason why I should delay this, please let me know by e-mail before 08:00UTC tomorrow. Thanks Dave

12 years, 10 months

LAVA Master Images

by Dave Pigott

Hi All, Something I've been meaning to do for a long time is synchronise the latest LAVA master images with lava-create-master, and I've now completed this and tidied things up. The definitive master images can now be found at: http://images.validation.linaro.org/lava-masters/ I've tidied the directory above this up, so if you were relying on the master images being there, please note the change. Thanks Dave

12 years, 10 months

← Newer
1
...
29
30
31
32
33
34
35
...
82
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation