canonical-ubuntu-qa team mailing list archive

[Robie Basak <2012514@xxxxxxxxxxxxxxxxxx>]

Hi Paride! Thank you for replying so quickly. FWIW, working around this
for $HOME at least was trivial now that I know about it, so there's no
urgency on this bug. I created it to help improve things over time, and
also have somewhere to link to from my workaround :)

On Wed, Mar 22, 2023 at 02:07:11PM -0000, Paride Legovini wrote:
> Let me try to recap to see if I got this right. $HOME is correctly set
> during the actual test run (_regardless_ of --shell-fail), but in the
> shell you are brought to by --shell-fail $HOME is not set. You were
> trying to use this environment to further develop the test, but the
> absence of $HOME got in the way. Is this correct?

Right. My test didn't work initially. I wanted to know why, so I used
--shell-fail (actually the shortcut -s). I designed my test to be
idempotent, so I expected to be able to reproduce the failure and
further develop the test from that environment. But $HOME is set during
the test run but wasn't set in my --shell-fail environment, so that led
to the test failing unexpectedly earlier for those reasons, which I
found confusing.

> It would be nice to make --shell and --shell-fail bring to the exact
> environment where the test run. However at the moment autopkgtest makes
> no promise in this regard...

This might be a feature request then :-)

>                             ...in general I don't think it can make a
> "hard" promise as the test run itself may have altered the system in a
> way that makes it impossible to recreate the same environment. (One
> random example: the test run alters the system hostname. How is
> autopkgtest going to "undo" that to recreate the environment before the
> test?)

I'd consider that my responsibility, not autopkgtest. I understand that
anything *my* test does will not be undone. But I'd like the environment
to otherwise be the same.

[...]

> autopkgtest uses different ways to get a shell in the testbed system,
> depending on the virt server in use. This is likely why noticed a
> difference when using the null virt server.

Probably just that the null virt server doesn't reset environment
variables? That seems reasonable, anyway.

On Wed, Mar 22, 2023 at 02:13:23PM -0000, Paride Legovini wrote:
> I tried following your steps to reproduce adding an "echo $HOME" before
> the "exit 1", and $HOME is there.

Right - $HOME is there during a regular test run (that's part of the
spec, in fact!), but not during --shell-fail (with the lxd runner at
least).

> Note that --shell-fail doesn't stop execution on failure and put you in
> the very environment where the test was executing, but opens a brand new
> shell to the testbed system.

I think that's OK, but I'd like for the new environment to be
initialized in the same way as the test run was.

-- 
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to autopkgtest in Ubuntu.
https://bugs.launchpad.net/bugs/2012514

Title:
  $HOME is not set in --shell-fail prompt

Status in autopkgtest package in Ubuntu:
  Incomplete

Bug description:
  Steps to reproduce:

  pull-lp-source hello
  cd hello-*
  # Stick "exit 1" into debian/tests/upstream-tests so it will fail
  dpkg-buildpackage -us -uc -S -sd -nc -d
  cd ..
  autopkgtest -s -B *dsc -- lxd ubuntu-daily:lunar
  echo $HOME

  # Actual behaviour: $HOME is unset; expected behaviour: $HOME is set

  $ dpkg-query -W autopkgtest
  autopkgtest     5.25ubuntu4

  I tried this on sid with the null runner, and $HOME was set correctly
  there. This might be a consequence of the null runner not resetting
  the environment (as might be expected), or point to a bug specifically
  in the lxd runner; I'm not sure.

  I did find that $HOME is set in the actual test run. But then my test-
  in-development started failing in other ways because $HOME was not set
  in the --shell-fail environment. What I expect is that the --shell-
  fail environment is identical; otherwise it's difficult for debugging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2012514/+subscriptions