RE: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD

["Moessbauer, Felix" <felix.moessbauer@siemens.com>]

> -----Original Message-----
> From: Anton Mikanovich <amikan@ilbers.de>
> Sent: Monday, November 29, 2021 3:20 PM
> To: Schild, Henning (T RDA IOT SES-DE) <henning.schild@siemens.com>
> Cc: Moessbauer, Felix (T RDA IOT SES-DE)
> <felix.moessbauer@siemens.com>; Schmidt, Adriaan (T RDA IOT SES-DE)
> <adriaan.schmidt@siemens.com>; isar-users@googlegroups.com; Baurzhan
> Ismagulov <ibr@ilbers.de>
> Subject: Re: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD
> 
> 29.11.2021 16:18, Henning Schild wrote:
> > Well that is to expect! I guess that patch did pass our gitlab based
> > CI, but i do not know.
> > Please give more details on the failure you see. "hash diff issue" ...
> > Otherwise we will be in the "works for me, vs have you tried turning
> > it off and on again" business.
> >
> >
> > Henning
> 
> As I've already mentioned before I've just run 'fast' CI (ci_build.sh -q -f -r) on
> Jenkins which failed on RebuildTest:
> 
> 19:27:22  (07/10)
> /build/isar_am_devel_fast/256/testsuite/build_test/build_test.py:RebuildTe
> st.test_rebuild:
> ERROR: When reparsing
> mc:qemuamd64-stretch:/workspace/build/isar_am_devel_fast/256/meta-
> isar/recipes-core/images/isar-image-base.bb:do_rootfs_postprocess,
> the basehash value changed from
> 6553fa78201729c3311387f6074b35e0bd2ec2d7e745044374c4736dab3c4829 to
> 562abcf3978252df402e4956d05bbbaed9e962ee379be1f9d85c43696e18f009.
> The metadata is not deterministic and this needs to be fixed.
> 
> Previous 6 test cases were passed.
> Analysis with bitbake-diffsigs gives the real cause:
> 
> basehash changed from
> 2d5398895dd3d1f478f58a07e1f411c4f4d374a4d9d2bbae7e3dfc1517f03278 to
> d459621430969975b7eed659471d4833ca17315e117c16ac1cc10e020886007a
> Variable IMAGE_BUILD_ID value changed from 'v0.7-537-g6085d11' to 'v0.7-
> 537-g6085d11-dirty'
> 
> Originally the repo was 'clean', then 'dirty' was caused by dummy
> do_fetch_append(){} added by the test.
> This test case emulates the scenario with adding some changes into the
> source and rebuilding the image.

That is what we expect. However something changes the git state during a build.
The state must ONLY be changed between builds (two bitbake invocations).
In case multiple tests are run in parallel in the same build-tree, this will break.
Even if the patches have not been fully tested in the CI, that's what we use in our daily business (it works).

Unfortunately I have a really hard time to run the CI in the Siemens environment, as it often fails due to proxy issues or network timeouts.
Also running just the repro target itself does not work due to other issues.
I tried with: avocado run testsuite/build_test/build_test.py:RebuildTest.test_rebuild

[stdout] E: Unable to find a source package for
[stdlog] 2021-11-30 10:58:04,196 cibuilder        L0100 ERROR| E: Unable to find a source package for
[stdout] + bb_exit_handler
[stdlog] 2021-11-30 10:58:04,196 cibuilder        L0100 ERROR| + bb_exit_handler

Anyways, if there are more issues to be ruled out for this patch series, I actually prefer to merge the SState series first.
Currently, a lot of patches are waiting for SState, as Henning mentioned.

Felix

> 
> --
> Anton Mikanovich
> Promwad Ltd.
> External service provider of ilbers GmbH Maria-Merian-Str. 8
> 85521 Ottobrunn, Germany
> +49 (89) 122 67 24-0
> Commercial register Munich, HRB 214197
> General Manager: Baurzhan Ismagulov