On 22.07.20 12:46, Daniel Sangorrin wrote:
-----Original Message-----Sorry for the confusion.
From: firstname.lastname@example.org <email@example.com> On Behalf Of Jan Kiszka
Sent: Wednesday, July 22, 2020 5:05 PM
To: sangorrin daniel(サンゴリン ダニエル □ＳＷＣ◯ＡＣＴ) <firstname.lastname@example.org>; email@example.com; iwamatsu
nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <firstname.lastname@example.org>
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt layer
On 22.07.20 09:25, email@example.com wrote:
________________________________________That would confuse me now: What creating a separate test image first, just to remove it again?
From: Jan Kiszka <firstname.lastname@example.org>
Sent: Wednesday, July 22, 2020 3:44 PM
To: email@example.com; sangorrin daniel(サンゴリン ダニエル
□ＳＷＣ◯ＡＣＴ); iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ)
Subject: Re: [cip-dev] [isar-cip-core] tests: put all tests into a opt
On 21.07.20 14:42, Daniel Sangorrin wrote:
having an opt-tests layer makes it easier to see what tests areJAN:
installed, and allows creating images without them as well
"Having ... as well."
Does this obsolete
where I just commented on?
DANIEL: Maybe you can apply Iwamatsu-san merge request first, and I will prepare a new patch on top of that to avoid confusion.
If you apply MR7, I will move the rt-tests and stress-ng packages from the customization "package" to the test image.
If you instead apply MR5, I will move them to opt-testtools.yml
Or is there any special reason for rt-tests and stress-ng to be in the customization package?
Nobuhiro, is something missing from your perspective in Daniels approach? If not, I'd like to have one patch that takes us to that level.
By now, I think an opt-testtools.yml is better (an "option", not a "layer") than a separate image. That allows to test the security image eventually as well.
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux