[tbot] [Discussion] Calling tbot from within the source directory

Stefano Babic sbabic at denx.de
Thu Nov 29 09:33:44 UTC 2018


Hi Claudius,

On 29/11/18 09:59, Claudius Heine wrote:
> Hi Stefano,
> 
> Quoting Stefano Babic (2018-11-29 09:32:05)
>> Hi Claudius,
>>
>> On 29/11/18 08:15, Claudius Heine wrote:
>>> Hi Harald,
>>>
>>> Quoting Harald Seiler (2018-11-28 17:40:09)
>>>> Hi Claudius,
>>>>
>>>> On Wed, 2018-11-28 at 15:40 +0100, Harald Seiler wrote:
>>>>> Hello Claudius,
>>>>>
>>>>> On Wed, 2018-11-28 at 15:22 +0100, Claudius Heine wrote:
>>>>>> Hi,
>>>>>
>>>>> [...]
>>>>>>
>>>>>> That is a bit tiresome. A `-C` parameter like git(1) has, would solve
>>>>>> it, but I think accessing the source code via the cwd in the testcases
>>>>>> as a fallback would be nice.
>>>>>>
>>>>>> I might just be my different understanding of things. I like to be in
>>>>>> the directory of the stuff that should be tested, not where the
>>>>>> testcases are located. It also makes sense for me if multiple source
>>>>>> directories need to be "tested" on the same hw.
>>>>>>
>>>>>> What do you think about this?
>>>>>
>>>>> Hmm, I never thought about running tbot from outside the "tbot-config"
>>>>> directory.  If you feel like this is needed for your workflow to be
>>>>> ergonomic, adding a -C parameter is definitely a good idea.  In terms
>>>>> of implementation, I'd suggest simply changing the working directory
>>>>> very early on in main if the -C parameter is present.
>>>>
>>>> I pushed a commit[1] implementing -C onto the development branch.  Please
>>>> try it out and tell me if it works as you need it to.  (Completions
>>>> should work as well! :)
>>>
>>> Thx a lot for the fast response. I wasn't expecting to have some code
>>> that fast.
>>>
>>> My only issue with this the `-C` solution is that it would be nice to be
>>> able to use the current working directory to refer to the code you want
>>> to test in the testcases.
>>
>> I am quite missing the point. Do you want to know in your test case
>> where the testcase file is stored ? Why ?
> 
> No, you misunderstood me.
> 
> I need to know in the test case where my source code is stored, not my test
> cases. For instance to compile and deploy my source code I need to know its
> path.

ok, thanks for explanation. It was not clear to me what you meant with
"sources" (source for test case or sources for linux / u-boot).

> 
>>
>> I think it is nice that testcase are simply stored and tbot recursive
>> scans for testcase and we do not need to know where they are, simple we
>> can use "import <testcase>".
>>
>>> Otherwise you will have to put the path to the
>>> code inside the testcase and that makes sharing most testcases pretty
>>> much impossible.
>>>
>>> Or do you have another solution, that I am not aware of for this?
>>>
>>> Setting environment variables for that is also a bit stupid and using an
>>> additional parameter is also overkill. Imagine that:
>>>
>>>     tbot -C /path/to/tbot-privat -l labs/my-lab.py -b boards/my-board \
>>>       -S "$(pwd)" my_test_case
>>>
>>
>> But if you need the current directory, can we add it as attribute for
>> the lab ? When tbot starts, set this attribute and you can access it in
>> your test case.
>>
>>> With `-S` as taking the path the the sources. Not as bad as the first
>>> example, but still a bit overcomplicated IMO.
>>>
>>> Otherwise if `-C` would work as a `change tbot configuration directory`,
>>
>> I supposed this is not the case - does tbot change directory ? I thought
>> -C adds the new directory to the search path.
> 
> Harald just created a new patch, see link in Harald message. He has
> implemented `-C` to switch to the directory before proceeding. What you
> mean is the `-T` parameter.
> 
>>
>>> then you could use the current working directory in your testcases, so
>>> you would not need an additional parameter or environment variable to
>>> point the the source-tree if you want to avoid having the path to it
>>> inside the testcases.
>>>
>>> I hope I made myself understandable, but I basically I would like to
>>> kill multiple birds with one stone:
>>>
>>>  1. Make calling tbot from outside the tbot configuration directory
>>>  easier.
>>>  2. Make it possible to use cwd inside testcases to point to the
>>>  source-tree -> make it easier to reuse/share testcases because they
>>>  would not need to contain the path to the source tree anymore.
>>
>> I can just imagine that you need, but if you could draft a simple real
>> testcase here, it is easier to understand the reasons.
> 
> Ok, here:
> 
> OUT="/home/ch/work/projects/my-project/out/build/tmp/deploy/images/machine"
> 
> @tbot.testcase
> def deploy_kernel(
>     lab: typing.Optional[linux.LabHost] = None,
> ) -> None:
>     with lab or tbot.acquire_lab() as lh:
>         with linux.lab.LocalLabHost() as local:
>             for f in [
>                 "machine-image.vmlinuz",
>                 "machine.dtb",
>                 "machine.initrd",
>                 "machine-image.fit",
>             ]:
>                 deploy_path = \
>                     linux.Path(lh, "/srv/tftpboot/boards/machine/") / f
>                 local_path = linux.Path(local, OUT) / f
>                 shell.copy(local_path, deploy_path)
> 
> If I the cwd would be inside the project directory already, then I could
> write:
> 
> OUT=os.getcwd() + "/out/build/tmp/deploy/images/machine"
> 

I assumed that this should be done with an upper testcase (that is not
shared) that calls your "general" testcase. So you have "deploy kernel"
(general) in this way:

@tbot.testcase
def deploy_kernel(
     lab: typing.Optional[linux.LabHost] = None,
     out: None,	
) -> None:

And then you have your own and specific testcase (that collects more
testcase, so it makes "composition" of testcases)

OUT="/home/ch/work/projects/my-project/out/build/tmp/deploy/images/machine"

import ...

@tbot.testcase
def test_my_board(
....
    lh = tbot.acquire.lab()

    deploy_kernel(lh, OUT)

This is lab (or better user specific, in this case) and it is not
shared, deploy_kernel is.

> @tbot.testcase
> def deploy_kernel(
>     lab: typing.Optional[linux.LabHost] = None,
> ) -> None:
>     with lab or tbot.acquire_lab() as lh:
>         with linux.lab.LocalLabHost() as local:
>             for f in [
>                 "machine-image.vmlinuz",
>                 "machine.dtb",
>                 "machine.initrd",
>                 "machine-image.fit",
>             ]:
>                 deploy_path = \
>                     linux.Path(lh, "/srv/tftpboot/boards/machine/") / f
>                 local_path = linux.Path(local, OUT) / f
>                 shell.copy(local_path, deploy_path)
> 
> I don't need the path to the source anymore and this testcase could be
> better used by multiple devs.
> 
> If the patch Harald applied to the developing branch would be used, I
> cannot do that in the testcase and would need some other mechanism to do
> that.
> 

Best regards,
Stefano

> Cheers,
> Claudius
> 
>>
>>>  3. Do this without need of any tbot configuration files or environment
>>>  variables or additional parameters.
>>>
>>> But of course this would change how tbot is used. Instead of always
>>> having the cwd inside the tbot configuration directory you would call
>>> tbot from the source-tree. IMO it makes more sense to call tbot from the
>>> source-tree than from the tbot configuration, since the primary work
>>> should be done while in the source-tree. But to discuss that I started
>>> this thread.
>>
>> Regards,
>> Stefano
>>
>>>
>>> Cheers,
>>> Claudius
>>>
>>>
>>>>
>>>> [1]: https://github.com/Rahix/tbot/commit/a2afa7c641f87c9cf4de6616a6136ca16a4650d3
>>>
>>>
>>>
>>>> -- 
>>>> Harald
>>>>
>>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
>>>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>>>> Phone: +49-8142-66989-62  Fax: +49-8142-66989-80   Email: hws at denx.de
>>>
>>> --
>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
>>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>>> Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de
>>>
>>>            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
>>>                              Keyserver: hkp://pool.sks-keyservers.net
>>>
>>>
>>> _______________________________________________
>>> tbot mailing list
>>> tbot at lists.denx.de
>>> https://lists.denx.de/listinfo/tbot
>>>
>>
>> -- 
>> =====================================================================
>> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
>> =====================================================================
> 
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de
> 
>            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
>                              Keyserver: hkp://pool.sks-keyservers.net
> 


-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================


More information about the tbot mailing list