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

Thu Nov 29 09:50:24 UTC 2018

Hi Stefano,

Quoting Stefano Babic (2018-11-29 10:33:44)
> 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.
> 

Thanks for that idea. This is possible, but on the other hand I would
need to have such wrappers for every testcase I want to use?

Haralds 'composition over configuration' is a very good idea, but IMO in
some cases that might become unhandy. Eighter we have some configuration
in there or we would need to make creating those wrappers so easy that
it can be done by command line parameter or configuration files.

Personally I don't like to type very long command line parameters
everytime and that is the reason I use tbot. So for me some
configuration files would be necessary.

Claudius

--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.denx.de/pipermail/tbot/attachments/20181129/a949816a/attachment-0001.sig>