Bug 10035 - oe-selftest: Use SSTATES without corrupting them.
Summary: oe-selftest: Use SSTATES without corrupting them.
Status: VERIFIED DUPLICATE of bug 10929
Alias: None
Product: Build Testing
Classification: QA/Testing
Component: general (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: High enhancement
Target Milestone: 2.3 M3
Assignee: Leonardo Sandoval Gonzalez
QA Contact: Jose Perez C
URL:
Whiteboard:
Depends on: 10929 10937
Blocks:
  Show dependency tree
 
Reported: 2016-07-26 21:02 UTC by Mariano Lopez
Modified: 2017-06-14 21:23 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: New (Never tested)
Verified:
Documentation change: Don't know

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mariano Lopez 2016-07-26 21:02:26 UTC 
Currently the oe-selftest run takes a lot of time to complete in the autobuilders. A speed up can be from using SSTATES when building the images and the SDK; the problem is the test could corrupt the SSTATES, so a cache would be needed.
Comment 1 Leonardo Sandoval Gonzalez 2016-08-31 15:05:36 UTC 
Due to time constrains, moving it to next enhancement window.
Comment 2 Benjamin Esquivel 2016-11-03 22:11:32 UTC 
I would like to see how the SSTATES get corrupted, how can I check this out?
Comment 3 Mariano Lopez 2016-11-03 22:20:25 UTC 
I have never actually seen this. I opened the bug because I was told that this was the reason for selftest not using SSTATES, I don't remember who said that.
Comment 4 Leonardo Sandoval Gonzalez 2016-11-04 21:23:10 UTC 
(In reply to comment #3)
> I have never actually seen this. I opened the bug because I was told that
> this was the reason for selftest not using SSTATES, I don't remember who
> said that.

Mariano, I believe 'corrupted' means that the shared states are touched by the selftests thus effectively changing the state.
Comment 5 Benjamin Esquivel 2016-11-07 17:50:54 UTC 
(In reply to comment #4)
> 
> Mariano, I believe 'corrupted' means that the shared states are touched by
> the selftests thus effectively changing the state.
This bug was filed as a result of a comment from RP and we've already discussed what corrupted means and it doesn't look like corrupted = changed in this case.
Comment 6 Richard Purdie 2016-11-07 17:54:21 UTC 
Corrupted here means that sstate gets deleted. Nothing on the autobuilder should run a "-c cleansstate".

The issue is that a build can be part way through running having checked sstate exists, then it can find it no longer does whilst its trying to use it.
Comment 7 Richard Purdie 2016-11-07 17:55:45 UTC 
We could just use the sstate as a read only mirror for oe-selftest to ensure that it can't delete things. Where a test needs to run an sstate clean, it could use "-f" to force a taint to a hash instead?
Comment 8 Benjamin Esquivel 2016-11-07 19:48:55 UTC 
(In reply to comment #7)
> We could just use the sstate as a read only mirror for oe-selftest to ensure
> that it can't delete things. Where a test needs to run an sstate clean, it
> could use "-f" to force a taint to a hash instead?

thanks for the clarification Richard.

Mariano, this looks like a way to start the investigation on this bug.
Comment 9 Benjamin Esquivel 2016-11-22 20:45:02 UTC 
Assigning it to Leo whom will try to get it done for M1.
Comment 10 Leonardo Sandoval Gonzalez 2017-01-24 16:25:20 UTC 
The is a newer bug (10929), filed by RP reporting an symptom of the main problem. Benjamin did some work on 10929 thus is more advance that this one. Making this as duplicated of 10929.

*** This bug has been marked as a duplicate of bug 10929 ***
Comment 11 Juan Ramos 2017-06-14 21:23:47 UTC 
Verified, tested with commit b6a1004c73820cff833f2b6f09d2432706f5447a, no SSTATES were corrupted after selftest