Currently, the binutils autopkg tests are disabled on the DebianCI
infratstructure, because the maintainers don't want to have a too long running
build.

The binutils autopkg tests include a binutils build, which should be triggered
when uploading a new glibc or gcc, however it's not necessary to build all
variants (multilib and cross binutils), so I'd like to disable these builds
during the autopkg tests.

Apparently the Ubuntu CI has an environment variable which can be asked for the
autopkg tests:

# only build the basic package when running the autopkg tests
ifneq (,$(ADT_TEST_TRIGGERS))
  CROSS_ARCHS :=
  with_hppa64 :=
  with_multiarch :=
endif

however the Debian CI doesn't set that.  So please either support running a
build with an environment variable set, or let an autopkg test run with a build
profile (e.g. autopkgtest).

Control: severity -1 normal
do this, except you have to start your build in your test script. You
can do:
Test-Command: X=y run-my-command

See e.g. how I set the temporary directory in dbconfig-common:
https://sources.debian.org/src/dbconfig-common/2.0.10/debian/tests/control/?hl=5#L5

Paul

no, you can't do this for the restriction "build-required". Any env var set for
the test command doesn't affect the build.

Hi Matthias,

That is why I said "you have to start your build in your test script".

Paul

Hi,

autopkgtest already sets several environment variables during the build,
so we're considering adding one that's specific for either autopkgtest,
or ci in general. "CI" comes to mind.

We would still need to align and agree on which variable.

Paul

For what it's worth, Gitlab CI and Github Actions both set CI=true as
one of their predefined environment variables, so if autopkgtest (and
ideally sadt) did the same, it would be straightforward to do whatever
"while running under CI" in a somewhat generic way.

The existence of AUTOPKGTEST_TMP in the environment is probably as good
a way as any to detect "we are under an autopkgtest-compatible runner"
more specifically than that. This is already available, and has been
since 2016. (sadt also sets this.)

Neither of those provide a way to tell the difference between "built as
a side-effect of autopkgtest" and "built for some other reason" for
test-cases that have the needs-build restriction. Does an autopkgtest
build-profile make sense for that? (autopkgtest already does set nocheck
and noudeb unconditionally, and cross if appropriate.)

Matthias' original use-case was wanting to disable the non-essential
parts of a binutils build (such as multilib) during autopkgtest. This
could be done either via a build-profile, or by checking for
AUTOPKGTEST_TMP in the environment. A build-profile would be necessary
if there was a desire to disable some build-dependencies, though.

     smcv

For what it's worth, Gitlab CI and Github Actions both set CI=true as
one of their predefined environment variables, so if autopkgtest (and
ideally sadt) did the same, it would be straightforward to do whatever
"while running under CI" in a somewhat generic way.

The existence of AUTOPKGTEST_TMP in the environment is probably as good
a way as any to detect "we are under an autopkgtest-compatible runner"
more specifically than that. This is already available, and has been
since 2016. (sadt also sets this.)

Neither of those provide a way to tell the difference between "built as
a side-effect of autopkgtest" and "built for some other reason" for
test-cases that have the needs-build restriction. Does an autopkgtest
build-profile make sense for that? (autopkgtest already does set nocheck
and noudeb unconditionally, and cross if appropriate.)

Matthias' original use-case was wanting to disable the non-essential
parts of a binutils build (such as multilib) during autopkgtest. This
could be done either via a build-profile, or by checking for
AUTOPKGTEST_TMP in the environment. A build-profile would be necessary
if there was a desire to disable some build-dependencies, though.

     smcv